Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

AbortSignal is ignored while waiting for retry backoff

Open
#205 0 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from browserbase/sdk-node

All issues in browserbase/sdk-node

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.