Add TRUNK_API_CLIENT_RETRY_DEADLINE_SECS to bound API retry time

[dfrankland]

Problem

The API client's retry loop (api/src/call_api.rs) only honored a retry count (TRUNK_API_CLIENT_RETRY_COUNT). Total wall-clock time was otherwise uncapped — per-request timeouts plus up to ~62s of exponential backoff (2/4/8/16/32s) across retries — so a slow/failing endpoint could spin for minutes (this is what surfaced the repeated …is taking longer than expected messages customers reported).

Change

• New optional env var TRUNK_API_CLIENT_RETRY_DEADLINE_SECS: an overall wall-clock budget for a call's retry loop. The loop gives up once elapsed + next_backoff >= deadline, returning the most recent error. Pairs with TRUNK_API_CLIENT_RETRY_COUNT to tune how fast/often the CLI gives up.
• Replaces tokio-retry's RetryIf with an explicit loop (behavior-identical when the deadline is unset) so the deadline can short-circuit while still returning a real error — the generic A::Error includes reqwest::Error, which has no public constructor, so a timeout()/select! wrapper couldn't synthesize one. We still use tokio-retry's ExponentialBackoff + Action.
• Read the env vars once via LazyLock (DEFAULT_DELAY, RETRY_DEADLINE).
• Captured TRUNK_API_CLIENT_RETRY_DEADLINE_SECS in TRUNK_ENVS_TO_CAPTURE for bundle-metadata debugging.

Notes

• The deadline is checked between attempts, so a single in-flight request can overshoot by up to its own reqwest per-request timeout (30s API / 1s telemetry); each attempt is already bounded by that timeout. Immediate mid-request abort on CI cancellation is handled separately in Abort the CLI immediately on SIGTERM/SIGINT (CI cancellation) #1132 (signal handling).
• Customer mitigations enabled by this: TRUNK_API_CLIENT_RETRY_COUNT=0 and/or a small TRUNK_API_CLIENT_RETRY_DEADLINE_SECS.

Testing

• Added two deterministic unit tests (paused clock, explicit deadlines): stops_retrying_once_deadline_would_be_exceeded and retries_full_count_when_no_deadline_set.
• All 9 call_api tests pass; existing retry-count/backoff/should_retry tests unchanged.

🤖 Generated with Claude Code

[trunk-io]

😎 Merged successfully - details.

[trunk-staging-io]

     

Failed Test	Failure Summary	Logs
variant_quarantine_test should be quarantined when run with variant	A test expected the sum of 2 + 2 to be 5, but it was 4, indicating a failing assertion.	Logs ↗︎

View Full Report ↗︎ ⋅ Docs

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.79%. Comparing base (83033bf) to head (857a7eb).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1131      +/-   ##
==========================================
+ Coverage   82.48%   82.79%   +0.30%     
==========================================
  Files          69       69              
  Lines       15482    15531      +49     
==========================================
+ Hits        12771    12859      +88     
+ Misses       2711     2672      -39     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[TylerJang27]

👍