Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Completed requests leak listeners on caller-provided AbortSignals

Aperta
#203 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@abhinavkr26104 ci sta già lavorando.

Dal 15/8/2026.

  • #208 di @abhinavkr26104 — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
api, backend

Direzione di ricerca

Inizia in src/core.ts, in fetchWithTimeout(), soprattutto alle righe 549-550, e traccia come le richieste vengono completate nei percorsi di successo, errore, timeout e retry. Aggiungi una copertura per la pulizia dei listener in ogni percorso e verifica che il riutilizzo di un unico AbortSignal fornito dal chiamante non lasci listener dopo il completamento delle richieste.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description

Every request made with a caller-provided AbortSignal permanently adds an abort listener to that signal.

At src/core.ts:549-550, fetchWithTimeout() calls:

if (signal) signal.addEventListener('abort', () => controller.abort());

The listener is never removed after the request settles. Reusing one signal across a batch therefore retains one internal AbortController closure per completed request.

Reproduction
import { getEventListeners } from 'node:events';
import Browserbase from '@browserbasehq/sdk';

const controller = new AbortController();
const client = new Browserbase({
  apiKey: 'test',
  maxRetries: 0,
  fetch: async () =>
    new Response('{}', {
      status: 200,
      headers: { 'content-type': 'application/json' },
    }),
});

for (let i = 0; i < 12; i++) {
  await client.get('/ok', { signal: controller.signal });
}

console.log(getEventListeners(controller.signal, 'abort').length); // 12
Expected behavior

A completed request removes its abort forwarding listener, leaving zero listeners after the loop.

Actual behavior

All 12 listeners remain attached. Retries add additional listeners because each attempt creates another controller.

Why this matters

Long-lived applications commonly share a signal across a batch of requests. Listener accumulation retains completed request state and can produce unbounded memory growth for large batches. The forwarding callback should be registered once/removed in cleanup (or use an equivalent combined-signal mechanism), with coverage for success, error, timeout, and retry paths.

Tested against @browserbasehq/sdk 2.18.0 / current main (b781bd7).

Lingua principale
TypeScript
Stelle
65
Fork
17
Merge medio
16m
PR unite (30g)
2

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di browserbase/sdk-node

Tutte le issue di browserbase/sdk-node

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.