[Flaky CI]: Node Node-Core Integration Tests - suites/cron/cron/test.ts > cron instrumentation

[github-actions]

Flakiness Type

Other / Unknown

Name of Job

Node (24) Node-Core Integration Tests

Name of Test

suites/cron/cron/test.ts > cron instrumentation

Link to Test Run

https://github.com/getsentry/sentry-javascript/actions/runs/28520820853/job/84545785206

---

This issue was automatically created.

[linear-code]

JS-2892

[github-actions]

I looked into this flaky test (suites/cron/cron/test.ts > cron instrumentation in Node-Core Integration Tests) but did not land a fix I'm confident enough in to open a PR. Notes for whoever picks this up:

What the test asserts

The runner (dev-packages/node-core-integration-tests/utils/runner.ts) matches envelopes in strict order via expectedEnvelopes.shift() and fails hard with Expected envelope item type '<x>' but got '<y>' on any mismatch. The scenario produces, in order:

1. check_in in_progress (run 1)
2. check_in ok (run 1)
3. check_in in_progress (run 2)
4. check_in error (run 2)
5. event (the thrown Error in cron job)

Hypothesis I ruled out

The obvious guess is that items 4 (error check-in) and 5 (exception event) race. They don't, at least not at the microtask level:

• finishCheckIn('error') → captureCheckIn → sendEnvelope calls transport.send synchronously (the loggingTransport just console.logs the envelope), so the error check-in is emitted in a single microtask hop.
• captureException routes through _captureEvent → _prepareEvent().then(...).then(...) (plus event processors / beforeSend), i.e. several deterministic microtask hops, and any source-reading is real async I/O (a macrotask) — always after the synchronous check-in.

So the exception event is deterministically emitted after the error check-in. Swapping the last two .expect() blocks would therefore be wrong and would make the test fail more often, not less.

What I suspect is actually happening

The remaining non-determinism lives in the cron library's wall-clock timer scheduling (* * * * * * fires every second) and/or the ~millisecond async window between the synchronous item 4 and the async item 5. Under a loaded CI runner a late/extra tick or a delayed flush could interleave unexpected output, or (less likely) the second tick could be delayed enough that the exception event isn't flushed before the scenario's setTimeout(process.exit, 15_000). I could not confirm which, because the failing job log (gh api .../actions/jobs/84545785206/logs) is not fetchable from this automated workflow.

Suggested direction

A robust fix probably needs either (a) order-independent matching for the check-in/event pair in the runner, or (b) restructuring the scenario so the exception event can't race with subsequent cron output — rather than a one-line tweak. I'd want the actual failure output (expected-vs-got line) from a failing run to pick the right one, so I'm leaving this for a human.

[JPeer264]

Same flake as #22847, which is the most recent occurrence. Consolidating there.