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 close fd exit 0 In other words, the USB backend gives up instead of trying again: it treats a failure to transfer the data as a permanent error.
Reported upstream.
http://www.cups.org/str.php?L715
The fix is crap. We should be reading status back from the printer, not just counting the bytes we threw at it.