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 is tightened (HTTP-date support) with broad test coverage and unchanged retry status sets.

Overview
Vendor-service retries (package-reference POST, archive GET, capped artifact GET, and resumed deferred downloads) now use the shared api::retry path for Retry-After and backoff timing instead of local helpers.

Retry-After is parsed via parse_retry_after on the client’s RetryHooks clock, so HTTP-date values are honored (still capped at VendorRetryPolicy::max_delay), not only delta-seconds. Backoff waits use hooks.sleep; jitter comes from the seeded retry_jitter keyed by request (constant for the reference POST, URL for downloads). Local retry_after_secs and unseeded jitter_sample() are removed; hint logic is centralized in vendor_retry_hint.

JVM jar patching and Maven sidecars switch inline SHA-1/SHA-256 hex helpers to utils::digest::{sha1_hex_of, sha256_hex_of}, with a small test ratchet update. New wiremock tests cover HTTP-date Retry-After across all four retry loops, cap behavior, and deterministic jitter from the hook seed.

^{Reviewed by Cursor Bugbot for commit 1d752aa. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

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 1d752aa. Configure here.}

[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