Which HTTP errors should never trigger an automatic retry?

Question

I\'m trying to make a few microservices more resilient and retrying certain types of HTTP requests would help with that.

Retrying timeouts will give clients a terribly s

Answer 1

There are some errors that should not be retried because they seem permanent:

• 400 Bad Request
• 401 Unauthorized
• 402 Payment Required
• 403 Forbidden
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required
• 409 Conflict - it depends
• 410 Gone
• 411 Length Required
• 412 Precondition Failed
• 413 Payload Too Large 
• 414 URI Too Long
• 415 Unsupported Media Type
• 416 Range Not Satisfiable
• 417 Expectation Failed
• 418 I'm a teapot - not sure about this one
• 421 Misdirected Request
• 422 Unprocessable Entity
• 423 Locked - it depends on how long a resource is locked in average (?)
• 424 Failed Dependency
• 426 Upgrade Required - can the client be upgraded automatically?
• 428 Precondition Required - I don't thing that the precondition can be fulfiled the second time without retring from the beginning of the whole process but it depends
• 429 Too Many Requests - it depends but it should not be retried to fast
• 431 Request Header Fields TooLarge
• 451 Unavailable For Legal Reasons

So, most of the 4** Client errors should not be retried.

The 5** Servers errors that should not be retried:

• 500 Internal Server Error
• 501 Not Implemented
• 502 Bad Gateway - I saw used for temporary errors so it depends
• 505 HTTP Version Not Supported
• 506 Variant Also Negotiates
• 507 Insufficient Storage
• 508 Loop Detected
• 510 Not Extended
• 511 Network Authentication Required

However, in order to make the microservices more resilient you should use the Circuit breaker pattern and fail fast when the upstream is down.