I had a similar thought a while back [0]. Developing a sane ontology of error types and their implications is a hard problem, but I think it could be done. The

I had a similar thought a while back [0]. Developing a sane ontology of error types and their implications is a hard problem, but I think it could be done. The subset of errors that is the most frustrating and hard to deal with are ones where, as you point out, the client will have no way to estimate how long a failure mode might persist, at which point you resort to exponential backoff (actually probably an s-curve). The issue is that sometimes the solution to the issue would require the client to get up and get out a shovel, and go dig somewhere or something. When the abstractions break down that hard there isn't really a way for the developer of the code to handle that unless they somehow stuff a full blown AGI into their program, and even then it would be a stretch. 0. https://github.com/tgbugs/idlib/blob/master/docs/identifiers.org#success-and-failure-modes-when-querying-a-system https://github.com/tgbugs/idlib/blob/master/docs/identifiers...