[Flaky CI]: Node Integration Tests - suites/tracing/mysql/test.ts > mysql auto instrumentation > diagnostics-channel (init opt-in) > should run streamed query listeners with the parent context active [esm]

[github-actions]

Flakiness Type

Other / Unknown

Name of Job

Node (26) Integration Tests

Name of Test

suites/tracing/mysql/test.ts > mysql auto instrumentation > diagnostics-channel (init opt-in) > should run streamed query listeners with the parent context active [esm]

Link to Test Run

https://github.com/getsentry/sentry-javascript/actions/runs/28412254578/job/84187969920

---

This issue was automatically created.

[linear-code]

JS-2888

[github-actions]

Automated flaky-test investigation (no fix opened)

I investigated the flake in suites/tracing/mysql/test.ts → diagnostics-channel (init opt-in) › should run streamed query listeners with the parent context active [esm] but did not open a PR, because I could not pin the flake to a specific, fixable mechanism with confidence. Sharing findings so a human can take it further.

What the test does

• scenario-streamContext.mjs issues a streaming connection.query('SELECT 1 + 1 AS solution') (no callback) and completes the root transaction span from inside the query's 'end' listener — span.end() only runs there.
• The channel instrumentation (packages/server-utils/src/integrations/tracing-channel/mysql.ts) defers the query span end to result.on('end' / 'error') and replays the caller scope onto the emitter via bindScopeToEmitter.

What I ruled out (appears deterministic)

• Span parenting: inner-span and listener-child are parented to the transaction by construction — _sentryCallerScope is captured at query() time (transaction active), and the instrumentation registers its 'end' handler synchronously before the scenario's, so ordering is fixed. I could not construct a nondeterministic path to any of the parent_span_id assertions failing.
• The in-process MySQL server (mysql-test-server.ts) frames packets correctly and replies per-connection without blocking.

Most likely remaining cause (unconfirmed): an intermittent timeout
The transaction is only sent once the streamed query's 'end' fires. If, under CI load, that stream settles via 'error' (or hangs) instead of 'end', the scenario's span.end() never runs and no transaction envelope is emitted, so the runner times out waiting for it. This is consistent with the "Other / Unknown" flake classification, but I could not reproduce it or point to the exact trigger from static analysis alone.

Why no fix was opened

• Any change I could make (e.g. also ending the transaction on 'error', or widening what the 'end' assertion accepts) would risk loosening the coverage this test is specifically meant to provide — it exists to prove streamed-listener context re-binding, so weakening it is not an acceptable "fix."
• The CI job log for the linked run was not retrievable in this automated environment, so I could not confirm whether the failure was a timeout or an assertion error.

Suggested next step for a maintainer: grab the failing job log and confirm failure mode (timeout vs. assertion). If it's a timeout, the fix likely belongs in making the streamed 'end'/'error' completion (or the shared in-process server under concurrent child-process load) deterministic, rather than in the assertions.

This comment was generated by an automated flaky-test triage run.