Skip to content

node:http client span never ends when the response is destroyed without an error (res.destroy()) #25469

Open

Description

@4ktLuffy

Is there an existing issue for this?

How do you use Sentry?

Sentry SaaS (sentry.io)

Which SDK are you using?

@sentry/node

SDK Version

11.8.0 (latest at the time of writing)

Framework Version

Node v25.8.0, plain node:http, no framework

Link to Sentry event

n/a, local repro (the DSN points at a local sink on 127.0.0.1)

Reproduction Example/SDK Setup

Self-contained, only needs npm i @sentry/node. It starts a local server that sends headers and
then streams a body, and a local DSN sink that collects the envelopes.

// Repro: http.client span is never ended when the response is destroyed mid-body.
// Usage: npm i @sentry/node && node nodehttp-repro.mjs
// Everything is local (127.0.0.1); no real DSN is used.
import * as Sentry from '@sentry/node';
import http from 'node:http';

// Local DSN sink: collects envelopes so we can see which spans were actually sent.
const sentSpans = new Map(); // url.full -> status, for http.client spans that reached the sink
const collect = o => {
  if (!o || typeof o !== 'object') return;
  const a = o.attributes || {};
  const url = a['url.full']?.value ?? a['url.full'] ?? o.data?.['url.full'];
  const op = a['sentry.op']?.value ?? a['sentry.op'] ?? o.op;
  if (op === 'http.client' && url) sentSpans.set(url, o.status);
  for (const v of Object.values(o)) if (v && typeof v === 'object') collect(v);
};
const sink = http.createServer((req, res) => {
  let body = '';
  req.on('data', c => (body += c));
  req.on('end', () => {
    for (const line of body.split('\n')) { try { collect(JSON.parse(line)); } catch {} }
    res.end('{}');
  });
});
await new Promise(r => sink.listen(0, '127.0.0.1', r));

Sentry.init({
  dsn: `http://k@127.0.0.1:${sink.address().port}/1`,
  tracesSampleRate: 1,
  // do not trace the sink itself
  ignoreOutgoingRequests: url => url.includes(`:${sink.address().port}`),
});

const ended = new Map(); // url.full -> status
Sentry.getClient().on('spanEnd', span => {
  const j = Sentry.spanToJSON(span);
  const url = j.attributes?.['url.full'] ?? j.data?.['url.full'];
  const op = j.attributes?.['sentry.op'] ?? j.op;
  if (op === 'http.client' && url) ended.set(url, j.status);
});

// Server that streams a slow body (headers sent, body never finishes on its own).
const srv = http.createServer((req, res) => {
  res.writeHead(200);
  res.write('first chunk');
  if (req.url.startsWith('/full')) setTimeout(() => res.end('rest'), 50);
});
await new Promise(r => srv.listen(0, '127.0.0.1', r));
const port = srv.address().port;

const cases = {
  full: res => { res.on('data', () => {}); },
  'res.destroy()': res => { res.once('data', () => res.destroy()); },
  'res.destroy(new Error())': res => { res.once('data', () => res.destroy(new Error('boom'))); },
};

await Sentry.startSpan({ name: 'root' }, async () => {
  for (const [name, handle] of Object.entries(cases)) {
    await new Promise(resolve => {
      const path = `/${name === 'full' ? 'full' : 'slow'}?case=${encodeURIComponent(name)}`;
      const req = http.get({ host: '127.0.0.1', port, path }, res => {
        handle(res);
        res.on('close', () => setTimeout(resolve, 300));
        res.on('error', () => {});
      });
      req.on('error', () => {});
    });
  }
});

await Sentry.flush(2000);
for (const name of Object.keys(cases)) {
  const path = `/${name === 'full' ? 'full' : 'slow'}?case=${encodeURIComponent(name)}`;
  const url = `http://127.0.0.1:${port}${path}`;
  console.log(
    name.padEnd(26),
    '| spanEnd fired:', ended.has(url) ? `yes (status=${ended.get(url)})` : 'NO',
    '| span in envelope:', sentSpans.has(url) ? `yes (status=${sentSpans.get(url)})` : 'NO',
  );
}
srv.closeAllConnections();
srv.close();
sink.close();
setTimeout(() => process.exit(0), 100);

Steps to Reproduce

  1. npm i @sentry/node@11.8.0
  2. Save the script above as repro.mjs and run node repro.mjs.
  3. Look at the three http.client spans: one for a fully read response, one where the client calls
    res.destroy() after the first chunk, and one where it calls res.destroy(new Error('boom')).

Expected Result

All three http.client spans end. A response that was cut off before the end should end the span
with an error status (the code already does this for an aborted response, see response.aborted
in finishWithResponse).

Actual Result

full                       | spanEnd fired: yes (status=ok) | span in envelope: yes (status=ok)
res.destroy()              | spanEnd fired: NO | span in envelope: NO
res.destroy(new Error())   | spanEnd fired: yes (status=error) | span in envelope: yes (status=error)

With res.destroy() the span never ends, so it is never sent.

I also checked the other ways to cut a request short after the response headers arrived. These
all end the span correctly: req.destroy() (error), req.destroy(new Error()) (error),
AbortController.abort() on http.request after the headers (ok, per #25260), and abort before
the response (ok).

Additional Context

Cause, in packages/core/src/integrations/http/client-subscriptions.ts on develop:

  • L143: the request close fallback (requestOnClose) is what ends the span if there is no response.
  • L168: as soon as a response arrives, that fallback is removed (request.removeListener('close', requestOnClose)),
    because the span should now end with the response.
  • L197-198: the only things that can end it after that are response.on('end', ...) and
    response.on(errorMonitor, ...).

res.destroy() without an argument emits neither end nor error on the response, only close
(and aborted). So nothing is left that ends the span. With res.destroy(err) the response emits
error, which is why that case works. The aborted check at L187 is only reached through those
two listeners, so it never sees this case.

This is the same kind of gap that #25260 (http client, abort is not an error) and #25129 (fetch) fixed
for aborts by the caller, but those only change the status of spans that already end. I could not find
an existing issue or PR for the span not ending at all. I searched open and closed issues and PRs for
http client span, destroy, aborted and leak. The closest are #25183 and #25209, which are the same
symptom for the Express request-handler span.

A fix would be to also end the span on the response close event (a no-op if end or error already
fired), with an error status when the response is incomplete. I have a patch with tests and can open a PR
if that direction is fine.

Activity

  1. linear-code commented on Oct 16, 2026

    @linear-code
  2. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Oct 16, 2026
  3. s1gr1d commented on Oct 19, 2026

    @s1gr1d
    Member

    Hello and thanks for already opening a PR, I will take a look at it!

  4. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions