fix: stop retries resending an acknowledged MT result - #326
Open
AliAlfaifi wants to merge 1 commit into
Open
AliAlfaifi wants to merge 1 commit into
AliAlfaifi wants to merge 1 commit into
Conversation
A retry deliberately bypassed the send guard so that the retries of an unacknowledged result would not be turned into no-ops by their own cache entry. It bypassed the guard unconditionally though, so a retry chain already in flight kept sending after a concurrent attempt had been acknowledged. Observed in production right after the deploy: one pair was acknowledged with a 100, then received three more sends from the retries of the attempt that had failed 272ms earlier. Store the outcome in the cache entry instead of a bare flag, and skip an acknowledged result even while retrying. A retry of an unacknowledged result still goes through, which is what the bypass was for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Summary
Follow-up to #325. A retry could still send a training-stage result that another attempt had already got acknowledged.
What #325 got wrong
The send guard skips a result already known to have been sent. Retries were made to bypass it, so that the retries of an unacknowledged result would not be turned into no-ops by the cache entry that attempt had just written. But the bypass was unconditional — it also ignored the acknowledged entry, so a retry chain already in flight kept sending after a concurrent attempt succeeded.
Observed in production
Within minutes of the #325 rollout, one
(learner, course)pair:Three surplus calls after the result was already accepted. Bounded by
max_retries=3, so it is a leak rather than a regression of the 121× duplicate storm #325 fixed — but it defeats the deduplication for exactly the pairs that succeed.The change
Store the outcome in the cache entry rather than a bare flag, and let the retry bypass apply only to the unacknowledged state:
acknowledgedunacknowledgedTesting
test_retry_is_skipped_once_acknowledged;test_retry_is_not_skipped_by_the_cacheupdated to seed the unacknowledged state so it still proves retries are not suppressed.633 passed, coverage 96% (--fail-under=93),pylint 10.00/10,pycodestyle,isortandflake8 --max-complexity 10all clean.🤖 Generated with Claude Code