fix: Honor explicit timeout timedelta larger than timeout_max

[vdusek]

An explicit per-call timeout timedelta larger than timeout_max (default 360 s) was silently clamped to timeout_max on every attempt, contradicting the documented behavior "A timedelta overrides it for this call". For example, dataset.get_items_as_bytes(timeout=timedelta(minutes=30)) ran every attempt with a 360 s timeout, causing repeated impit.TimeoutException and failing the call despite the explicit 30-minute request.

Root cause: _compute_timeout used min(resolved * 2**(attempt-1), timeout_max), so min() shrank the resolved base timeout to timeout_max even on attempt 1, before any exponential growth. The fix caps growth at max(timeout_max, resolved) instead, so the base timeout is never shrunk below itself while retry growth stays bounded.

✍️ Drafted by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.66%. Comparing base (c1bffc6) to head (2ecbeea).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #962      +/-   ##
==========================================
+ Coverage   94.64%   94.66%   +0.01%     
==========================================
  Files          58       58              
  Lines        5263     5263              
==========================================
+ Hits         4981     4982       +1     
+ Misses        282      281       -1     

Flag	Coverage Δ
integration	92.60% <100.00%> (+0.30%)	⬆️
unit	83.94% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

[Pijukatel]

Can you please verify in the API code that a timeout larger than 360 s has any meaning?

If there is some hard-coded or implementation limit on the API side, it makes no sense to lift the limit in the client.

(But a warning might be good in those cases)

[vdusek]

Probably, there are mostly idle timeouts, not wall-clock timeouts, so this could make sense. See:

Verified in apify-core — yes, it has meaning. The 360 s on the server side is an idle timeout, while impit's timeout is a total wall-clock budget, so the client cap was stricter than anything the API enforces.

• The only 360 s on the path is the ALB idle timeout on the api.* ingress (deploy/helm/helmfile.yaml:306); api.apify.com goes straight to that ALB. It fires only when no bytes flow for 360 s.
• No wall-clock cap on responses: no requestTimeout/keepAliveTimeout override (src/api/src/lib/api_server.ts:208), no timeout middleware, and respondWithDatasetItemsStream (lib/datasets.ts:541) streams with no deadline. The API even writes a space every second to keep the socket busy (lib/actor_jobs.ts:147, routes/datasets/items.ts:147) — it's built for requests outliving the idle timeout.
• Verified impit's semantics: a 6 s stream that's never idle >1 s still fails at exactly 3.0 s under timeout=3. So a 10-minute export is legal server-side but the old min() aborted it at 360 s — the reported failure.
• Server-side caps that do exist are all below 360 s and return a proper response: MAX_ACTOR_JOB_SYNC_WAIT_SECS = 300 / ASYNC = 60. Node's default requestTimeout = 300 s does hard-cap uploads (408), but that's a case for raising it on the API side, not for silently shrinking an explicit user value.

I don't want to waste much time here. IMO, silently truncating it is definitely wrong. If we don't want to allow longer timeouts, we should at least log a warning. However, allowing longer timeouts wouldn't be harmful anyway. I'll wait for your response, but I don't have a strong preference here.