Bug

[electrowizard]

No, you shouldn't just keep resending the same request when there isn't a success signal on the first one. It needs to instead send requests that just verify that the connection before it resends the other request. This is in the HTTP standards for persistent connection design lmao

[KrazyKat]

@_jdance

Ghandi had a very low violence level and anything causing his level to decrease set it to the max possible

Because it was set as an unsigned integer!
When his aggression went to -1, it went 255 on a scale of 1 to 10, so he went crazy.

[_jdance]

Yes, you should. Packets get lost all the time. If it didn't request again, a lot more people would be experiencing annoying posting errors regularly instead of just you

[_jdance]

Frankly you're wrong

[big_ass]

For reference the max safe integer in js is 9007199254740991 and in ruby apparently they automatically convert when there is an overflow but even if you did something really obscure (like override this functionality by allocating a specific amount of memory - no reason they would have done this in discourse) you still get something like 4294967295 or 2147483647

For reference I got all this info from 5 mins of googling which is the first thing you should be doing when you want to report the forum is dying due to your pet bug theory - you can google first "discourse back end what language" and then "int js max value" and "ruby max safe integer"

Should we help ewiz google for his issue next?

[electrowizard]

This isn't fucking true. That should only be done when the HTTP request doesn't change anything server-side (idempotent requests). PUT requests, like posting a reply, will change things server side. Since discourse uses a persistent connection, non-idempotent requests should not be resent when there's no server response until they verify the persistent connection works.

Check out section 8.1 of the HTTP standards.

[electrowizard]

@big_ass

Should we help ewiz google for his issue next?

Maybe you should google what should happen when there's no server response to a request in persistent connection web services.

[big_ass]

@electrowizard

No, you shouldn't just keep resending the same request when there isn't a success signal on the first one. It needs to instead send requests that just verify that the connection before it resends the other request. This is in the HTTP standards for persistent connection design lmao

Great, then you can go to the discourse website and educate them on network design

[big_ass]

Electrowizard vs. Jeff Asswood. A real meeting of the mind

[_jdance]

I'm not reading any manuals. I'm going to tell you off the top of my head what the best design is based on intuition and years of making decisions

[_jdance]

What do I think the best design is? Definitely not one that uses the word impotent. That's just upsetting

[_jdance]

Also - you're persistently annoying

[SOPHIE]

@electrowizard

People have posted about the intermittent connection issue before. Atwood is just a dumbass that doesn't accept any of his design choices could be poor, so the response is always "use recommended settings for limiting time between posts," which is dumb. It's the same thing with very long threads breaking: he'll never fix it because he'll never admit it's a problem that needs to be fixed

/thread

[SOPHIE]

you arent?

[big_ass]

If you're not encouraging ewiz to go post on discourse meta you're griefing this thread

[electrowizard]

I know there's no point in arguing with Atwood on his own forums, but I can expose you as a dumbass.

@big_ass

And the other benefit is that you might get an education about how these things work and why something would be designed that way (to resend a request when it doesn't receive a success signal on the first one) so you can stop posting here about how it's all very very dumb that you turn off your wifi and get weird network issues (and then ruin the blog thread because of it)

@HTTP Protocol Standards

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.

Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.

@HTTP Protocol Standards

Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request sequence is idempotent (see section 9.1.2). Non-idempotent methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation

https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

[big_ass]

Yeah see your approach is just wrong from the start because you think you would be going there to "argue" with them (meaning share things you think you already know) rather than listen to them (meaning discover things you didn't know)

Yours is the approach of a person who chronically knows next to nothing and sabotages projects with egoism and belligerence but at least you're googling now (even if it is just to try and prove yourself right)

[electrowizard]

Unfortunately, my project for the past month has been doing full-stack development. I didn't have to Google this shit: I already knew it from my job. The design decision here is wrong or there's a bug they aren't fixing. The fact that you keep spewing bullshit about how uninformed and dumb I am while being demonstrably wrong is insane

[_jdance]

You've been doing full stack for like a month? That's a lot of pancakes. Unfortunately Atwood has been eating pancakes for far longer than you. He obviously knows better

[electrowizard]

No, I just had to do it for the past month. It's what I did for a long time, but got to move to shit that doesn't suck. And Atwood is smart, but he's wrong in this instance. Just because there's a config that stops the problem from being visible doesn't mean the problem shouldn't be fixed.