4 ms·

> You still return 409 No no no no no. You have multiple clients submitting the same business operation simultaneously. One must succeed, the others must fail

> You still return 409 No no no no no. You have multiple clients submitting the same business operation simultaneously. One must succeed, the others must fail. If you're using the 409 approach ("notify client that request is redundant") you must not send a 409 code until the work is complete. The client must interpret 200 and 409 as success cases. 200 means "it was done" and 409 means "it was already done". Clients looping (say, processing durable queue messages) can stop when they receive these responses. If the work is not complete, you can't return 409, or clients will think the work is done. You will lose messages.

pdonis 5mo ago
> You have multiple clients submitting the same business operation simultaneously. It doesn't have to be multiple clients. It could be the same client, not having received a response to its first request and deciding to re-send the request again.
- stickfigure 5mo ago
  That's fine! It doesn't change anything.
ASalazarMX 5mo ago
What's the best practice here? It's trying to represent as binary a multi-state operation, but the redundant clients should check the response's body to know why it 409'd. If the process is slow, it can't return a 200 immediately, and yet it should return 409 to all other attempts, even if the initial attempt ends up unsuccessful.
- fc417fc802 5mo ago
  > and yet it should return 409 to all other attempts, even if the initial attempt ends up unsuccessful. No, it shouldn't. The comment you're responding to is taking 200 to mean "success" and 409 to mean "it was done" so if it was not in fact done then you _must not_ return that. That said, I thought one of the benefits of idempotency was nonblocking APIs so I'm not sure I like that scheme. It seems like 200 should mean "submitted, accepted, incomplete" and 409 should mean "previously completed". The client never knows which request succeeded but they're idempotent so that doesn't matter. You just poll until the 200 becomes a 409. Of course that would provide zero diagnostics in the case of failure so I think it's not sufficient as described.

pdonis 5mo ago

> You have multiple clients submitting the same business operation simultaneously. It doesn't have to be multiple clients. It could be the same client, not having received a response to its first request and deciding to re-send the request again.

stickfigure 5mo ago
That's fine! It doesn't change anything.

ASalazarMX 5mo ago

What's the best practice here? It's trying to represent as binary a multi-state operation, but the redundant clients should check the response's body to know why it 409'd. If the process is slow, it can't return a 200 immediately, and yet it should return 409 to all other attempts, even if the initial attempt ends up unsuccessful.

fc417fc802 5mo ago
> and yet it should return 409 to all other attempts, even if the initial attempt ends up unsuccessful. No, it shouldn't. The comment you're responding to is taking 200 to mean "success" and 409 to mean "it was done" so if it was not in fact done then you _must not_ return that. That said, I thought one of the benefits of idempotency was nonblocking APIs so I'm not sure I like that scheme. It seems like 200 should mean "submitted, accepted, incomplete" and 409 should mean "previously completed". The client never knows which request succeeded but they're idempotent so that doesn't matter. You just poll until the 200 becomes a 409. Of course that would provide zero diagnostics in the case of failure so I think it's not sufficient as described.