When there is no queue, if the process fails, the inbox can just respond with a 500 server error and the sender will resend it.
But with a queue, by the time the inbox responds, it doesn't know if the process will fail because it hasn't run yet. So the sender won't retry whether it fails or not.
So, should it have its own retry logic when there is a queue?
@hongminhee yeah, basically there's a lot of undefined's here, iirc. I know @hrefna has done a lot of research around queues for AP, and also maybe @helge
This is part of what makes distributed systems so much more complex than non-distributed systems: once you have done the 200/202 response you are then responsible for the handling and if you haven't communicated back a way for them to find out what happened to it you can't expect them to do anything differently unless it is part of a negotiated protocol.
Trying to solve this is ultimately how we get things like the FLP result and the PACELC theorem.
Nope! That behavior is specified in C2S interactions—where the server returns once it has actually created the object and returns the id of the new object (so not a status URI, but something that you can check nonetheless)—but there's no such specification in S2S interactions (where the spec says basically nothing about return codes).
Both Helge and I have written proposals around this at different points and we've talked about it, but there's nothing in the spec or that would be easy to get widespread adoption on.