docs(kanban): clarify unblock always resets the retry budget - #27
Merged
Conversation
kanban_unblock intentionally zeroes consecutive_failures on every manual unblock (kanban_db.py unblock_task) -- this is the correct, by-design behaviour, not a circuit-breaker accounting bug. Document it next to the --max-retries description so operators understand a --max-retries 1 task can legitimately run more than once when a human unblocks it between failures. Ref: t_cc469a2f diagnosis (reproduced against live gave_up events for t_6193fa6e and t_8680bbb7 -- failures==effective_limit in both cases, arithmetic correct; the extra runs came from manual kanban_unblock resets between breaker trips). Decision: Rook, option 1 (accept working-as-designed, no dispatcher/kanban_db.py code change).
૮ >ﻌ< ა ci reviewran on 1221634 — docs(kanban): clarify unblock always resets the retry budget
|
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
1 participant
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
Adds one clarifying paragraph to
website/docs/user-guide/features/kanban.mdnext to the--max-retriesdescription: a manualkanban unblock/kanban_unblockalways resetsconsecutive_failuresto zero (by design, perunblock_task()inkanban_db.py). This means a--max-retries 1task can legitimately consume more than one dispatch attempt if a human unblocks it between breaker trips — that is expected operator-driven behaviour, not a circuit-breaker accounting defect.Background
Investigated as t_cc469a2f (SME-flagged "max_retries accounting bug", citing t_6193fa6e: 3 runs against max_retries=1, and t_8680bbb7: 2 runs against max_retries=1). Reproduced the exact accounting path against live
gave_uptask_events for both tasks: in every casefailures == effective_limitat the moment the breaker tripped (arithmetic is correct, matches the documented--max-retries 1contract). The extra dispatch attempts were caused entirely by a human callingkanban_unblockafter judging the trip to be a transient/environmental false failure (single-query-mode-c/-eiteration-budget exhaustion) — which resets the retry budget by design (kanban_db.pyunblock_task(), comment: "a deliberate unblock is a fresh start for the retry budget").Rook's decision: accept as working-as-designed (option 1) — no dispatcher/
kanban_db.pycode change, only this documentation clarification so operators aren't surprised by the interaction.Test Plan
fork/main(no other divergence pulled in)--max-retriesparagraph, same section)Closes t_cc469a2f (Kanban board t_cc469a2f).