DWC retries all XHR requests

[tomasf]

When the "Maximum number of AJAX retries" setting is greater than zero, DWC retries all XHR requests. Retrying passive things like status updates is fine, but it also retries [c]rr_gcode[/c], for example, which can result in the code being executed several times (if the request arrives on the Duet side, but the response isn't delivered successfully). Under unfavourable circumstances, this could lead to the head crashing into the bed, for example.

[chrishamm]

Well, I really don't see how this could create any problems. When an AJAX request times out, the browser resets the connection by sending a RST packet to the Duet. As a consequence, the Duet will discard the incoming data as soon as it is received, effectively purging any data packets associated with this connection.

The "AJAX retries" field was primarily introduced for the first generation of the DuetWiFiServer firmware, but thanks to dc42 the stability has been vastly improved when DuetWiFiSocketServer 1.19.2 was released. That is another reason why I don't think we should worry about this any more.

[tomasf]

XHRs can fail at any time along the lifecycle of an HTTP transaction. You can never be sure whether or not the server received a message and processed it.

I've reproduced this using a network link conditioner that simulates a bad network. It doesn't take many attempts at sending a G28 before it double-homes. (I've also seen it happen when I'm not even trying, but it's always difficult to be sure it wasn't just me accidentally double-clicking.)

[tomasf]

Caught this actually happening today when pausing a print, resulting in a "Error: Printing is already paused!!" message after receiving the duplicate command.