All errors are assigned to the same trace when tracing is disabled

[mnow-cd]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/node

SDK Version

10.43.0

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

test.ts:

import * as Sentry from '@sentry/node';
import express from 'express';

const app = express();

app.get('/', async (_req, res) => {
    Sentry.captureException(new Error('Test Error'));
    Sentry.logger.info('Test Log');
    res.end('ok');
});

app.listen(3000, () => {
    console.log(`App listening on port 3000`);
});

instrument.ts:

import * as Sentry from '@sentry/node';

process.loadEnvFile();
Sentry.init({
    enableLogs: true,
});

node --import ./src/instrument.ts src/test.ts

Node.js v25.8.1, Express.js v5.2.1

Steps to Reproduce

1. go to http://localhost:3000 a few times
2. check sentry ui for trace id

Expected Result

Each event should have a different trace id

Actual Result

When tracing is disabled all errors from different requests are assigned the same traceId.
This is visible in the Trace Preview:

Trace logs:

Additional Context

Shouldn't each request have a unique traceId even when tracing is disabled (tracesSampleRate is undefined)? This behavior can be quite confusing during debugging. It creates a false impression that unrelated errors/logs are part of the same request or execution flow.

If this is the intended behavior, is there a way to manually generate/reset a new traceId for each request without enabling tracing?

Ref: #17101, #18517

I've posted this originally as a question #19610

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear-code]

JS-1942

[Lms24]

Hi, thanks for writing in! I can reproduce this. Gonna take a look at what we can do to fix this. I agree. As long as our httpIntegration is used, we should isolate traces per request.

[Lms24]

I opened #19835 to explicitly recycle the traceId on our fallback propagationContext, tracing is disabled. This should fix your issue and likely also resolve some of the linked ones.
We'll publish the fix with the next release

[mnow-cd]

Thanks for the quick fix. Looking forward to the release