[Flaky CI]: Node (24) (TS 3.8) Integration Tests - suites/tracing/amqplib/test.ts > amqplib auto-instrumentation > esm/cjs > esm > should be able to send and receive messages

[github-actions]

Flakiness Type

Other / Unknown

Name of Job

Node (24) (TS 3.8) Integration Tests

Name of Test

suites/tracing/amqplib/test.ts > amqplib auto-instrumentation > esm/cjs > esm > should be able to send and receive messages

Link to Test Run

https://github.com/getsentry/sentry-javascript/actions/runs/26030287555/job/76514895508

---

This issue was automatically created.

[linear-code]

JS-2527

[mydea]

Investigated this via /fix-issue (Claude Code). Aborting without a PR — fix is non-trivial.

Root cause

From the failing run:

FAIL suites/tracing/amqplib/test.ts > amqplib auto-instrumentation > esm/cjs > esm > should be able to send and receive messages
Error: Expected envelope item type 'transaction' but got 'event'.
Item: [{"type":"event"}, {"exception": {"values": [{"type":"Error","value":"Socket closed abruptly during opening handshake", ...}]}}]

The scenario's first await amqp.connect(...) rejects with Socket closed abruptly during opening handshake — RabbitMQ's TCP port (5672) is open but the broker isn't yet accepting AMQP protocol handshakes. The rejection bubbles up as an unhandled promise rejection in the scenario, OnUnhandledRejection catches it and sends it as an error envelope, and the strict runner at utils/runner.ts:509 throws because it expected a transaction envelope next, not an event.

The docker-compose healthcheck (rabbitmq-diagnostics -q ping) signals "healthy" earlier than full AMQP-protocol readiness, so there's a race window where the runner launches the scenario but the broker can't yet complete the AMQP handshake.

Why aborting

Three candidate fixes, each with non-trivial risk and none is a clear one-liner:

1. Add retry loop to connectToRabbitMQ() in scenario.mjs. Smallest code change (~7 lines), but it modifies code that talks to an external service (which the skill explicitly cautions against), and there's no existing retry pattern in sibling docker-based scenarios (kafkajs, postgres, prisma) to mirror — making the symmetric-pattern verification fail.

2. Replace the docker-compose healthcheck with one that actually verifies AMQP readiness (e.g. rabbitmq-diagnostics check_port_connectivity or rabbitmq-diagnostics check_running). Picking the right command requires RabbitMQ-specific confidence I don't have, and a wrong choice could mask a different failure mode.

3. Make utils/runner.ts more tolerant of out-of-order error envelopes when a transaction is expected. Broadest blast radius — affects every integration test in the suite, not just amqplib.

The cleanest fix here is probably (1), but it crosses the "modify external-service code" boundary the skill calls out, and no sibling does it. Flagging for someone closer to the integration-test infrastructure to choose.