Retryable responses are abandoned without canceling their bodies
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- node.js, typescript
- Domain
- api
Research direction
Start at the retry branch in src/core.ts:490-495 and run the provided reproduction to observe the un-canceled response body. Add runtime-compatible cleanup before retryRequest(), then test cancellation for both Web and Node stream implementations, confirming the first response is canceled before the retry.
Written by the indexing model from the issue text.
Description
Description
When an HTTP response is retryable, the SDK starts the next attempt without consuming or canceling the previous response body.
The early return at src/core.ts:490-495 bypasses response.text() and does not call response.body.cancel() (or the runtime-equivalent cleanup) before retryRequest().
Reproduction
import Browserbase from '@browserbasehq/sdk';
let attempts = 0;
let cancelCalls = 0;
const client = new Browserbase({
apiKey: 'test',
maxRetries: 1,
fetch: async () => {
attempts++;
if (attempts === 1) {
const body = new ReadableStream({
cancel() {
cancelCalls++;
},
});
return new Response(body, {
status: 500,
headers: { 'content-type': 'text/plain' },
});
}
return new Response('{}', {
status: 200,
headers: { 'content-type': 'application/json' },
});
},
});
await client.get('/retry');
console.log(cancelCalls); // 0
Expected behavior
The unused body of the first response is canceled before retrying (cancelCalls === 1).
Actual behavior
The response is abandoned without cancellation (cancelCalls === 0).
Why this matters
With streaming or large error responses, abandoning the body can keep sockets and stream resources occupied, reduce connection reuse, and accumulate resources across repeated 429/5xx responses. The retry branch should explicitly cancel the body in a runtime-compatible way and test both Web and Node stream implementations.
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
-
VerificationGate: ATTRIBUTION quote guard never matches a normal quotation (\b around the quote) Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
danielmiessler/LifeOS#2234 ·
-
T: Bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Mend: dependency security vulnerability untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 70/100