Repository navigation
Additional error actions apply to the open-ended attempts of indefinite policies - #5259
Merged
Merged
Conversation
…te policies Follow-up to #5252. FailureRule.InfiniteSource was a bare continuation source, so actions chained with AndPauseProcessing(), AndPauseSending() or And(...) never reached the attempts it covers: - ScheduleRetryIndefinitely(1m, 5m).AndPauseProcessing(10m) paused on attempts 1 and 2, then retried every 5 minutes without pausing - RequeueIndefinitely().AndPauseProcessing(...) never paused at all - the same gap for CustomActionIndefinitely() and for ContinueWith() after attempt 1 The rule now keeps its infinite source in a FailureSlot of its own, and FailureActions applies additional actions to it while it belongs to the current segment of the chain (Then clears it, as it already clears the numbered slots). InfiniteSource still returns the source that was set, because the Kafka and Pulsar transports read it to recognise their native policies. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DCggXgxnG3EBXoR9rrq37U
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #5252 (johnkaram02), which made actions chained after
ScheduleRetryIndefinitely()apply to its listed delays. As that PR's description pointed out, the attempts after the listed delays still came fromFailureRule.InfiniteSource, which is a bare continuation source with nowhere to put additional actions.Given
The same gap made
RequeueIndefinitely().AndPauseProcessing(...)never pause at all. It also dropped additional actions fromCustomActionIndefinitely(), and fromContinueWith()after its first attempt.Change
FailureRulekeeps its infinite source in aFailureSlotof its own (InfiniteSlot) and builds the open-ended attempts from it, so they combine with additional actions exactly as a numbered slot does.InfiniteSourcestill returns the source that was set, with no actions attached. The Kafka and Pulsar transports read it to recognise their native policies, and Pulsar sets it directly.FailureActionsappliesAndPauseProcessing/AndPauseSending/And(...)to that slot while it belongs to the current segment of the chain.Thenclears it, as it already clears the numbered slots, soScheduleRetry(1m).AndPauseProcessing(5m).Then.RequeueIndefinitely()does not pause on the requeues.FailureRule.ToString()describes the open-ended attempts with their additional actions.Tests
FailureRuleCollectionTestsgets five tests:ScheduleRetryIndefinitelykeeps pausing after its listed delaysRequeueIndefinitely().AndPauseProcessing(...)CustomActionIndefinitely(...).And<...>()The first three fail on
mainand pass with this change.Local verification (net9.0, Release):
dotnet build wolverine.slnx -c Release -f net9.0: clean🤖 Generated with Claude Code
https://claude.ai/code/session_01DCggXgxnG3EBXoR9rrq37U