alkhttp/tasks/client/review-002-cli01-retry-after-budget.md at bb709bd10186f85934a78d838a9023283eb0ba08

Files

T

glm-5.3-flash e2c255d40c docs(tasks): decompose review-002 into 24 tasks (23 implementation + 1 bracketed follow-up)

Decomposition of docs/reviews/002-post-remediation-review.md per its
5-unit remediation plan:

- Unit 1 (security-critical): gw15-publish-body-cap,
  prj16-schema-via-call (CF-004 filed alkcall-side), fwd13-dot-segments,
  fwd16-missing-capability, oai11-ref-memoization
- Unit 2 (timeout/terminality): ws13-idle-progress,
  fwd15-stream-timeout, cli01-retry-after-budget, con17-mcp-pagination,
  con18-wss-sweep-exit
- Unit 3 (projection/docs): projection-truthfulness, mcp-batch-cap,
  gw16-status-drift
- Unit 4 (spec-import): yaml-normalization, oai13-path-item-wildcards,
  import-loudness-cluster, js01-placeholder-check,
  fwd17-19-contract-decisions
- Unit 5 (WS polish + tests): con18b-ws-polish,
  client-policy-wire-tests, cov-deployment-knobs, cov13-dead-code,
  srv11-srv12-router-ordering
- review-002-bracketed-followup: tentatively planned post-bulk pass
  (stale-check, OQA-18 enforcement decision, CON-08/09 close() lever,
  cross-crate re-checks) — deliberately not serialized against the
  bulk

Also: review-002 numbering repair (CON-14 was double-booked; MCP
pagination now CON-14, from_wss monitor renumbered CON-18, missing
CON-14 section added).

taskgraph: 66 valid, no cycles; 24 pending (all review-002);
gen-1/gen-2 parallel waves identified; workflow-cost hotspots are
prj16 (12.8) and ws13 (11.1), both carrying the reviewed slicing
guidance in their Notes.

2026-08-30 10:50:34 +00:00

3.2 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level, tags

name

status

depends_on

scope

risk

impact

level

Description

Review 002 CLI-01 [major]. The Retry-After middleware sleeps outside the retry budget and re-arms a full ceiling on every throttled retry — middleware order is RetryGateMiddleware outside RetryAfterMiddleware (http_client.rs:511-520), so every retry attempt re-enters RetryAfterMiddleware::handle:

attempt 1 → 429 + Retry-After: 300 → deadline recorded t₀+300
reqwest-retry sleeps ≤ 2 s, retries
attempt 2 re-sleeps until t₀+300 (inside maybe_sleep_for), gets a fresh 429 → deadline re-armed to t₀+302 (a full new 300 s)
… for up to max_retries more → ~15 min wall time inside one forward() call

TotalRetryBudget gates only its own backoff sleeps; the 30 s request timeout never covers this window (the sleep happens before the reqwest request is constructed, so the timer never starts).

Acceptance Criteria

maybe_sleep_for is budget-aware: caps the sleep by the remaining max_total_retry_duration (check inside the sleep — the pending sleeps, clamped, or checks-and-skips when the budget is spent; implementer's choice, but a deadline that would extend past the budget must be truncated to it)
Re-arm clamp: record_if_throttled keeps the earliest deadline (or otherwise does not extend past the first-seen deadline for the same URL within one logical request) — a retry storm cannot push the wall clock out ceiling-per-attempt
Wire test: counting responder that always answers 429/Retry-After: N with the test's ceiling set small → the caller's total wall time is bounded by max_total_retry_duration + one attempt's request time (assert the bound, not the exact count)
The per-URL deadline map semantics for separate logical requests are unchanged (a fresh request still honors the recorded throttle window — that feature stays)
Fix the misspelled test name malware_records_under_the_effective_url while touching the file
cargo test, cargo clippy --all-targets -- -D warnings, cargo fmt --check pass

References

docs/reviews/002-post-remediation-review.md (Part D', CLI-01)
src/client/http_client.rs:511-520 (stack order), 370-395 (TotalRetryBudget), src/client/retry_after.rs:44-62 (ceiling), :127-211 (record/maybe_sleep)
tasks/client/review-001-client-timeout-retry.md (the Retry-After machinery)
tasks/client/review-002-client-policy-wire-tests.md (the counting-responder seam this test family shares)

Notes

Keep the semantics decision narrow: the goal is "one logical request's Retry-After waits are bounded by the retry budget," NOT changing the cross-request throttle map (FWD-11's eviction/jitter behavior is already fixed and correct). The natural seam is threading the budget handle into the middleware order so RetryAfter sees it — small, testable, no public API change (the budget is already a HttpClientConfig field).

3.2 KiB Raw Blame History

Description

Acceptance Criteria

References

Notes

3.2 KiB

Raw Blame History