test(node-core): Fix flaky cron instrumentation test

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254

[github-actions]

Summary

Fixes the flaky suites/cron/cron/test.ts > cron instrumentation test in the Node-Core Integration Tests.

Root cause

The test asserts a strict, ordered sequence of envelopes, ending with the error check_in followed by the error event:

check_in (in_progress) → check_in (ok) → check_in (in_progress) → check_in (error) → event

For the failing cron tick, withMonitor emits the error check_in and captureException emits the error event back-to-back. captureException defers its actual transport send (async event preparation), while the check-in is sent synchronously — so the send order is deterministic (check-in first, event second).

However, this scenario was the only cron-error test still using .withMockSentryServer(). That mock server observes envelopes in network arrival order, not send order. The two envelopes are sent close together over HTTP (potentially on different sockets), so their arrival order at the server is non-deterministic. When the event arrives before the error check_in, the runner's in-order matcher hits a type mismatch (Expected envelope item type 'check_in' but got 'event') and the test fails.

Fix

Switch the scenario to loggingTransport (and drop .withMockSentryServer()), exactly like the sibling cron-error tests in the same directory tree (node-cron/base, node-schedule) that are not flaky. loggingTransport logs each envelope to stdout at send() time, so the runner observes envelopes in deterministic send order, eliminating the network arrival-order race.

The assertions are unchanged — the test still exercises the identical 5 envelopes (statuses, monitor_config, trace contexts, and the error event). Only the observation mechanism changes to a deterministic one.

Fixes#21254