fix: correct retry backoff units

[roshnicdave]

Fixes generic retry backoff delays being treated as seconds. Telegram retry_after values remain in seconds.

Tests: deno task test, deno task check, deno fmt --check, deno lint.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 41.62%. Comparing base (b04bfee) to head (dde7b98).
⚠️ Report is 142 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #960      +/-   ##
==========================================
- Coverage   45.52%   41.62%   -3.90%     
==========================================
  Files          19       19              
  Lines        5520     7238    +1718     
  Branches      360      461     +101     
==========================================
+ Hits         2513     3013     +500     
- Misses       3003     4142    +1139     
- Partials        4       83      +79     

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

[frederico-kluser]

Ran into this same bug independently and opened #961 (issue, with a reproduction) and #962 (PR) before finding this one — my mistake, I searched issues but not pull requests. I have closed #962; this PR was first and is the one that should land.

Two small things from mine that might be worth folding in here, entirely up to you and @KnorpelSenf:

1. The docstring ceiling no longer matches the constant. withRetries says:

Never waits longer than 1 hour before retrying.

Before the fix that was wrong in the other direction (the ceiling was effectively ~13.9 days). After the fix the real ceiling is 20 minutes, matching the named constant TWENTY_MINUTES. So the prose is now off by 3×. Either the docstring should say 20 minutes, or TWENTY_MINUTES was meant to be an hour and the constant should change — a maintainer call, but it is currently inconsistent either way.

2. Why the suite never caught it, which might be worth a line in the PR body: the two existing retry tests assert callCount === 2, i.e. the initial attempt plus the first retry — and the first retry is deliberately immediate, since if (lastDelay !== INITIAL_DELAY) is false on the first pass. So sleep was never reached by any test. Your new test is the first one that drives a second retry. (The should retry on 429 errors test does advance a fake clock by 30000 for retry_after: 30, which is consistent with sleep taking seconds and passes because that call site was already correct.)

#961 has a self-contained reproduction that needs no Telegram token and no network access to api.telegram.org — it points client.apiRoot at a local server that destroys every connection. Measured on 1.45.1:

t=   0.01s  method=getMe         gap=   0.00s
t=   0.01s  method=getMe         gap=   0.00s     <- 1st retry, immediate
t= 100.02s  method=getMe         gap= 100.00s     <- 2nd retry: 100 seconds

Happy to help however is useful — reviewing, testing, or nothing at all.

[KnorpelSenf]

This is an ugly fix. Instead of converting the units back and forth several times, we should instead refactor the code to use time units consistently everywhere.

Also, the tests are just slop. I will do this myself.