AbortSignal is ignored while waiting for retry backoff
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- api
Research direction
Start at retryRequest() in src/core.ts:595-630 and trace how options.signal is handled by makeRequest(). Verify the supplied reproduction; done when aborting during the 500 ms retry delay rejects promptly with APIUserAbortError and normal retry behavior remains intact.
Written by the indexing model from the issue text.
Description
Description
Aborting a request while it is waiting to retry does not interrupt the retry delay. The SDK waits for the full Retry-After/backoff period before it notices the signal is aborted.
retryRequest() uses an unconditional await sleep(timeoutMillis) at src/core.ts:595-630. The caller's options.signal is only checked when makeRequest() starts the next attempt.
Reproduction
import Browserbase from '@browserbasehq/sdk';
let attempts = 0;
const client = new Browserbase({
apiKey: 'test',
maxRetries: 1,
fetch: async () => {
attempts++;
return new Response('{}', {
status: attempts === 1 ? 429 : 200,
headers: {
'content-type': 'application/json',
'retry-after-ms': '500',
},
});
},
});
const controller = new AbortController();
const started = Date.now();
const request = client.get('/retry', { signal: controller.signal });
setTimeout(() => controller.abort(), 20);
await request.catch((error) => {
console.log(error.constructor.name); // APIUserAbortError
console.log(Date.now() - started); // ~500 ms, not ~20 ms
});
Expected behavior
The retry wait is abortable, so the promise rejects with APIUserAbortError promptly after about 20 ms.
Actual behavior
The promise does not reject until the complete 500 ms retry delay has elapsed. A long server-provided Retry-After value makes cancellation ineffective for that entire period.
Why this matters
Abort signals are used to release work when requests, jobs, or incoming HTTP connections are canceled. Keeping canceled operations pending through retry delays wastes resources and makes shutdown/cancellation latency unpredictable. The delay should race against the signal and clean up its listener/timer on either outcome.
Tested against @browserbasehq/sdk 2.18.0 / current main (b781bd7).
- Dominant language
- TypeScript
- Stars
- 64
- Forks
- 17
- Avg merge
- 13m
- Merged PRs (30d)
- 4
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from browserbase/sdk-node
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
browserbase/sdk-node#202 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
browserbase/sdk-node#197 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
browserbase/sdk-node#193 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
browserbase/sdk-node#180 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 66/100
browserbase/sdk-node#218 · 2 comments ·
All issues in browserbase/sdk-node
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
vercel-labs/just-bash#464 ·
-
looksLikeSlug() is ASCII-only, so non-Latin entity slugs (e.g. Korean) skip exact match and collapse Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
TanStack/tanstack.com#1293 ·