404 retries? too much?
zkat opened this issue · 0 comments
The nature of mfh's retry logic is that it'll take a bit of extra time in exchange for improved robustness against unexpected conditions.
The reason for retrying 404s is that sometimes things take a few moments to propagate and become available, and it's nice to not just fail right away if that happens.
That said, I feel like retrying 404s causes some usability issues, where users who try and hit an endpoint have to choose between finding out right away that a certain thing is unavailable, or not retry at all for any errors.
So, I'm thinking of doing one of two things:
- add an option to explicitly enable 404 retries on user request
- disable 404 retries altogether, and let users do their own retries for this code if they think there's a strong enough reason to believe it'll be helpful (it's a fairly rare case).
I'm leaning towards #2
here, pretty strongly. 404s are way too common to force users to wait on retry logic to be done. The other codes are much more likely to be ephemeral failures than 404 is, too.