From 5f6eb0e192ee7040d367aab881b7cbbeca26e0d9 Mon Sep 17 00:00:00 2001 From: Claude Code Bot Date: Sat, 18 Apr 2026 14:02:30 -0700 Subject: [PATCH 1/2] =?UTF-8?q?docs:=20clarify=20that=20timeout=20uses=204?= =?UTF-8?q?4%=20buffer=20(1.20=20=C3=97=201.20),=20intentional?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Closes #26. The prior comment advertised "+20% buffer" but the math actually applies 1.20 twice — once in the MAX_TURNS calculation and once in TIMEOUT_SECS = MAX_TURNS * 30 * 1.20, compounding to 1.44 × the raw turns-times-30s baseline. The compounding is INTENTIONAL: the two buffers protect against different failure modes. - The turn-side buffer protects against Claude using more turns than estimated — "exceeded turn limit" in the step error. - The wall-clock-side buffer protects against infrastructure flakes (backend latency, network stalls) that don't consume turns but still eat wall time. Before the AAR 2026-04-17, a single session saw three consecutive infra-flake timeouts on kebab-tax#1162 — extra wall-clock slack reduces that rate. Closes the docs-vs-code mismatch flagged in #26 by documenting the compound factor and the rationale. No code change — the intentional extra slack stays. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/workflows/claude-blocking-review.yml | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/.github/workflows/claude-blocking-review.yml b/.github/workflows/claude-blocking-review.yml index 4dffbee..a2a97c6 100644 --- a/.github/workflows/claude-blocking-review.yml +++ b/.github/workflows/claude-blocking-review.yml @@ -249,7 +249,21 @@ jobs: fi # --- Timeout estimation --- - # ~30s per turn as baseline, +20% buffer, minimum 4 minutes + # ~30s per turn as baseline, with a second 20% buffer on top of the + # max_turns value (which already carries its own 20% buffer from the + # turn estimation above). Compounded factor = 1.20 × 1.20 = 1.44 — + # so the timeout is ~44% over the raw `turns × 30s` baseline. + # This is INTENTIONAL: a max_turns exhaustion is what Claude hits + # when its budget runs out mid-run (produces "exceeded turn limit"); + # a wall-clock timeout is the outer safety net for infrastructure + # flakes (network stalls, backend pressure) that don't consume turns + # but still eat wall-clock. Keeping slack on the wall-clock side + # means flakes that would otherwise kill the step instead give + # Claude room to recover and finish. The AAR 2026-04-17 documented + # three consecutive infra-flake timeouts in one session on + # kebab-tax#1162 — extra slack is the right posture. + # Bounds: 4 min floor (very small diffs still need checkout + + # action setup + 15-turn minimum), 30 min ceiling. if [ "$TIMEOUT_INPUT" -gt 0 ]; then TIMEOUT="$TIMEOUT_INPUT" echo "timeout_minutes override: $TIMEOUT" From 146830205c252bbb82448acf71e4895264c7fd65 Mon Sep 17 00:00:00 2001 From: Claude Code Bot Date: Sat, 18 Apr 2026 14:04:13 -0700 Subject: [PATCH 2/2] docs: mark timeout 4m/30m bounds as defensive-only at current MAX_TURNS Local reviewer flagged that the preceding comment overstated the role of the floor and ceiling clamps. With MAX_TURNS bounded to [15, 40] by the estimator (PR #52) the computed timeout is always 9-24 minutes, so neither the 4 min floor nor the 30 min ceiling ever activates in normal operation. They are defensive against future parameter drift, not active bounds today. Closes #54. No code change. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/workflows/claude-blocking-review.yml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/.github/workflows/claude-blocking-review.yml b/.github/workflows/claude-blocking-review.yml index a2a97c6..c1af300 100644 --- a/.github/workflows/claude-blocking-review.yml +++ b/.github/workflows/claude-blocking-review.yml @@ -262,8 +262,12 @@ jobs: # Claude room to recover and finish. The AAR 2026-04-17 documented # three consecutive infra-flake timeouts in one session on # kebab-tax#1162 — extra slack is the right posture. - # Bounds: 4 min floor (very small diffs still need checkout + - # action setup + 15-turn minimum), 30 min ceiling. + # At current bounds (MAX_TURNS ∈ [15, 40]) the computed timeout is + # always 9–24 min, so the 4 min floor and 30 min ceiling are + # DEFENSIVE — they only activate if a future change lowers the + # MAX_TURNS floor below 8 or raises it above 50. The caller-side + # timeout_minutes validation in Validate inputs enforces a hard + # upper bound of 30 regardless of what the estimator computes. if [ "$TIMEOUT_INPUT" -gt 0 ]; then TIMEOUT="$TIMEOUT_INPUT" echo "timeout_minutes override: $TIMEOUT"