See the sentence "when this happens, CUPS loses the print job which
was currently being spooled" in #122827.
Cups shouldn't see this as a successful print job. The page was not
printed -- and probably wasn't even completely sent to the printer, or
the printer would have printed it. I suspect CUPS will lose the job
even if the printer is disconnected for other reasons during printing.
Certainly the acknowledgment had not been received from the printer
telling us that it had actually been rendered.
Seems that backends are meant to handle retries themselves. This is
what the USB backend currently does:
while (stuff to do)
try writing to fd
if it failed, break
In other words, the USB backend gives up instead of trying again: it
treats a failure to transfer the data as a permanent error.
The fix is crap. We should be reading status back from the printer,
not just counting the bytes we threw at it.