nats-architecture-and-design: Pull Request Error/Warning Handling

We can take this offline - the guidance we are looking for is errors that are transient, and the client can re-attempt - Here’s how I would have mapped them: 1xx - Heartbeats, Flow Control, etc, - libraries or user code can handle this how they want. 204 - No messages - request succeeded but there is no content to give, try again. 400 - client requests that exceed limits on the consumer (still think that the server should clamp a larger value from a client to the consumer config value) - this request will never succeed unless the request options change 404 - Not found (doesn’t exist), this will never succeed unless something else changes (resource is created) 408 - for server signaled timeout (request ended, so client can ask again) 410 - This is a direct lookup of message that was deleted. 412 - for things like mismatch between consumer configuration and access pattern 429 - MaxWaitingExceeded or too many acks pending (asks the client to slow down)

In all cases these codes can be handled blind - meaning there should be no code on a client that tries to parse the description of the status to determine what to do.

429 is too many requests.