Retrying 202

[sanscheese]

Setting 202 as a status code for retries doesn't seem to trigger retries on 202 responses. Should it?

I'm guessing it's seeing 2XX as successful. Looking at the docs for 202 response it would make sense to be able to retry this status code.

[sindresorhus]

202 means the server accepted the request but hasn’t finished processing. Retrying risks duplicating work or causing side effects. It's not an error; it's intentional deferral. The correct pattern is polling a status endpoint, not resending the request.

[sholladay]

Maybe we could check the Location header and then poll the request status automatically.

[sindresorhus]

That behavior is app-specific, not HTTP-generic. 202 + Location has no standardized semantics. Polling logic depends on API guarantees, timing, and side effects. A general HTTP lib like Ky shouldn’t assume any of that.

[joelbutcher]

@sindresorhus what HTTP status code would you expect to be returned from an endpoint that should be polled?

For example, if a status for an object can be either pending, completed or failed, would you expect the HTTP code returned from the server to be the same for each status (i.e. a 200)?

[sindresorhus]

I would use 200. The object status (pending, completed, failed) should be in the response body, not the HTTP status.

[sholladay]

I like to use 202 Accepted while it's still in progress. But 200 OK as Sindre described is definitely more common.