Feature request
Add a way for retry policies to define failures that should bypass retry handling and be raised immediately, even when they would otherwise match a retry rule.
Problem
Applications often use broad retry rules for transient failures, but some errors are known to be permanent or business-rule failures. Retrying those errors wastes time, delays failure handling, and can make logs noisier or harder to interpret.
Common examples include:
- Validation or uniqueness failures that cannot succeed on retry
- Business-rule exceptions that should fail fast
- Broad retry policies where a smaller subset of matching failures must be excluded
- Exception classes where only certain messages represent non-retriable cases
Desired behavior
- Users can mark specific exception cases as non-retriable.
- Non-retriable matches are raised immediately without consuming additional attempts.
- Exclusions take precedence over broader retry matches.
- Matching works with exception subclasses.
- Message-specific exclusions are supported where useful.
- The behavior works consistently for per-call and default/global retry configuration.
- Documentation and tests cover precedence, subclass matching, and message-specific matching.
Notes
This request is based on the behavior proposed in #107, but the final API should be decided separately.
Feature request
Add a way for retry policies to define failures that should bypass retry handling and be raised immediately, even when they would otherwise match a retry rule.
Problem
Applications often use broad retry rules for transient failures, but some errors are known to be permanent or business-rule failures. Retrying those errors wastes time, delays failure handling, and can make logs noisier or harder to interpret.
Common examples include:
Desired behavior
Notes
This request is based on the behavior proposed in #107, but the final API should be decided separately.