What is the problem this feature would solve?

This pattern is very common in distributed systems as it solves cascading failures and allows services to recover instead of sending requests that are bound to fail. Personally, I faced an issue with on a project with a 3rd party integration that locked your account if you sent multiple authentication requests. A circuit breaker pattern solved this issue for me.

What is the feature you are proposing to solve the problem?

Here's how a circuit breaker pattern works:

The Circuit Breaker typically has three states:

• Closed: The circuit is functioning normally, and requests are allowed to pass through.
• Open: The circuit has detected failures (e.g., a certain number of consecutive failures or a threshold percentage of failures) and stops forwarding requests. During this state, requests are typically rejected immediately, or a fallback mechanism is triggered.
• Half-Open: After a timeout period, the circuit breaker transitions to a half-open state to test if the underlying problem has been resolved. A limited number of requests are allowed through. If these requests succeed, the circuit transitions back to the closed state. If they fail, it goes back to the open state.

For a more detailed explanation Martin Fowler's blog post is useful: https://martinfowler.com/bliki/CircuitBreaker.html

What alternatives have you considered?

I've worked with a custom circuit breaker as well in a couple of languages but generally in the Node ecosystem I've used Opossum: https://github.com/nodeshift/opossum. However, this feature would be very useful in this project, since it already has a retry capability, the next step could be to add more resilience patterns. I've seen libraries in other languages that have a collection of resiliency patterns including in .NET and Java but haven't seen that in Typescript yet.