Honor HTTP-date Retry-After on vendor-service retries through api::retry (#677)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #677

Summary

Vendor-service retries (the package-reference POST, the archive GET, the capped artifact GET and a resumed deferred GET) now read Retry-After through api::retry::parse_retry_after and draw their jitter from the seeded api::retry::jitter_sample, on the client's RetryHooks. The private, weaker copies in api/client.rs are deleted.

Why

Register row C15 (child 1 of tracking #676), living document doc/07-infra-agent.md ("Three retry systems in one module"). Leverage: B 0 (no separate bug issue), U 1 (child 2 of #676, which merges the retry loops, needs this), D ≈2 (retry_after_secs, jitter_sample()), R L. Score ≈4. It was the best candidate that no open PR overlaps.

What changed

• New ApiClient::vendor_retry_hint(status, headers): retryable status → parse_retry_after(headers, hooks.now_unix_secs()). It replaces the three vendor_status_retryable(..).then(|| retry_after_secs(..)) sites.
• vendor_backoff(key, retry, retry_after) takes jitter from retry_jitter(hooks.jitter_seed, key, retry), keyed by the archive or artifact URL, or by a constant key for the reference POST. It waits on hooks.sleep, which is tokio's sleep by default. VendorRetryPolicy::delay still maps the sample onto ±25% and caps at max_delay.
• Deleted: retry_after_secs (delta-seconds only) and jitter_sample() (unseeded RandomState).
• Ported from Bound registry downloads by ApiTimeouts instead of a 60 s total deadline (#872) #876 (commit 28d4d52, cherry-picked unchanged): production_digests_go_through_the_helpers fails on main because Full Gradle support in agent, hosted and vendored modes #646 added inline JVM digests. This is the same change Bound registry downloads by ApiTimeouts instead of a 60 s total deadline (#872) #876 carries, so it becomes a no-op once that PR lands.

Size (git diff --stat)

• api/client.rs: production +36 / −36 (net 0 after rustfmt wrapping; the two helpers are gone), tests +173 / −2.
• Port: production +10 / −22 across jvm_jar.rs and sidecars/maven.rs, plus 1 line in the test ratchet.

Behavior

• A vendor 429/5xx whose Retry-After is an HTTP-date now waits until that date, still capped at max_delay (4 s by default). Before this, it fell back to the 400 ms → 4 s backoff.
• Jitter is drawn from the per-process seed. The range is unchanged (±25%).
• Nothing else changes: same retryable status set (vendor_status_retryable), same attempt counts and request sequences.

Test evidence

• New every_vendor_retry_loop_honors_an_http_date_retry_after: all four former callers wait exactly 2 s on Retry-After: <date 2 s ahead>. New an_http_date_retry_after_is_capped_at_max_delay covers the cap. New vendor_backoff_jitter_replays_from_the_hook_seed: the same seed gives the same waits, another seed gives different ones, and every wait stays within ±25% of nominal.
• Red→green: with the hint temporarily switched back to the old delta-seconds parse, the first two tests fail. With the shared parser, they pass.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-core --lib: 5249 passed. The 4 known root-only failures remain (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_…, pypi_requirements::wire_failure_…).
• cargo test -p socket-patch-cli --all-features --test covgap_commands_vendor --test cli_scan_silent --test covgap_commands_get: all pass except 3 tests that need a read-only directory and fail when run as root in the sandbox (*_state_write_failure_* in covgap_commands_vendor; they chmod a directory). These pass in CI.

Risk

Low. One file of production code. The vendor retry suites (vendor_retry_tests, vendor_prefetch tests) pass with unchanged request sequences.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HegUKEf6caV6QASRt7z8iX

---

Note

Low Risk
Retry timing and jitter change for vendor HTTP calls only; behavior aligns with existing api::retry semantics and is covered by new tests.

Overview
Vendor-service retry backoff now goes through the shared api::retry helpers instead of local copies in client.rs.

Retry-After is parsed with parse_retry_after (delta-seconds and HTTP-date), using RetryHooks::now_unix_secs, so a date-based header is honored up to max_delay. Retry hints are centralized in vendor_retry_hint for package-reference POST, archive GET, and capped artifact GET paths.

Backoff jitter comes from retry_jitter(hooks.jitter_seed, key, retry)—a fixed key for the reference POST, the URL for downloads—and waits use hooks.sleep rather than hard-coded tokio::time::sleep. The old retry_after_secs and unseeded jitter_sample helpers are removed.

New tests assert HTTP-date Retry-After (2 s wait) across all four retry loops, cap behavior, and deterministic jitter from the hook seed.

^{Reviewed by Cursor Bugbot for commit 5077cab. Configure here.}

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

[agent] CI on 1d752aa was hit by a runner loss, not by a failure in this PR. At about 20:45Z the runners received a shutdown signal (coverage log: "The runner has received a shutdown signal", exit 143, in the middle of e2e_vendor_pypi_build with every test passing up to that point). About 45 jobs across CI, npm, pnpm, Benchmarks and Audit GHA ended cancelled, and none ended with a test failure. I re-ran the cancelled jobs once in Audit GHA Workflows, Benchmarks, npm hosted/vendored compatibility and pnpm hosted compatibility. The main CI run is queued again. The PR #889 workflow run refuses a re-run (403 "cannot be retried"), so it needs the next push or a maintainer re-run. Locally: clippy is clean, and socket-patch-core --lib passes apart from the 4 known root-only tests. The digest ratchet that is red on main is ported here from #876. Handing this PR to the burn-down routine.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 1d752aa (1d752aa49bd5f19f31428b849a7ded8392ab9db9).

• CI: 402/402 workflow checks green on the head commit (6 skipped by matrix rule), after re-running jobs the GitHub Actions runner outage cancelled. No test failed. The only non-green entries are 2 CodeQL default-setup Analyze jobs that GitHub cancelled during the outage, and GitHub doesn't allow re-running them ("This workflow run cannot be retried").
• Bugbot: reviewed 1d752aa with no new issues, and no review threads are open.
• Mergeable against main, with no conflicts.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 5077cab. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] Ready for review at 5077cab (merged as 835601b while CI was finishing).

• Merged origin/main into the branch after Fix main CI red on stale digest pending-list entries #1016 landed. The merge was clean: this branch's PENDING_INLINE_DIGESTS change was identical to Fix main CI red on stale digest pending-list entries #1016's, so the diff vs main is now only api/client.rs.
• Local checks: production_digests_go_through_the_helpers and the 128 api::client tests pass, and rustfmt is clean. Local cargo clippy --workspace --all-features -D warnings on macOS stopped on an unused unix_default variable in crawlers/python_crawler.rs. This PR doesn't touch that file, and the CI clippy job passed.
• CI on 5077cab: 232 pass, 4 skipped, 0 failing.
• Bugbot: success on 5077cab, no open threads.

Generated by Claude Code