test(node): Make amqplib v1 integration test order-independent by github-actions[bot] · Pull Request #21534 · getsentry/sentry-javascript

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-06-15T12:28:50Z

Summary

Fixes the flaky amqplib v1 auto-instrumentation integration test (suites/tracing/amqplib-v1/test.ts).

Root cause

The test asserted the producer (root span) and consumer (queue1 process) transactions in a fixed order using two sequential .expect() callbacks. The runner matches expected envelopes strictly FIFO (expectedEnvelopes.shift()), so the first callback always runs against whichever transaction envelope arrives first.

The producer and consumer are independent traces flushed independently, so their arrival order at the test server is not guaranteed. When the consumer (queue1 process) envelope arrived before the producer (root span) envelope, the first assertion expect(transaction.transaction).toEqual('root span') failed against the consumer transaction.

This is the same flake — and the same fix — already documented in the kafkajs integration test (suites/tracing/kafkajs/test.ts), which collects both transactions and asserts after both are received.

Fix

Apply the established collect-then-assert pattern: push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name, span count, PRODUCER span shape, consumer name, CONSUMER trace context) are preserved — only the order dependency is removed.

Fixes#21173

## Summary Applies the same fix as #21534 (amqplib **v1**) to the non-versioned `amqplib auto-instrumentation` test (`suites/tracing/amqplib/test.ts`), which has the identical flaky pattern. ## Root cause The test asserted the producer (`root span`) and consumer (`queue1 process`) transactions in a fixed order using two sequential `.expect()` callbacks. The runner matches expected envelopes strictly FIFO, but the producer and consumer are independent traces flushed independently, so their arrival order at the test server isn't guaranteed. When the consumer envelope arrived first, the first assertion (`expect(transaction.transaction).toEqual('root span')`) failed against the consumer transaction. ## Fix Use the established collect-then-assert pattern (same as #21534 and the `kafkajs` test): push both transactions into an array, then look them up by transaction name and assert once both have arrived. All original assertions (producer name + span count + PRODUCER span shape, consumer CONSUMER trace context) are preserved — only the order dependency is removed. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(node): Make amqplib v1 test order-independent
8c15b94
Fixes#21173

github-actionsBot requested a review from a team as a code owner June 15, 2026 12:28

github-actionsBot requested review from JPeer264 and mydea and removed request for a teamJune 15, 2026 12:28

mydea approved these changes Jun 15, 2026
View reviewed changes

mydea enabled auto-merge (squash) June 15, 2026 12:45

mydea disabled auto-merge June 15, 2026 12:46

mydea mentioned this pull request Jun 15, 2026
test(node): Make amqplib integration test order-independent #21541
Merged

mydea enabled auto-merge (squash) June 15, 2026 12:49

mydea merged commit 31841e4 into developJun 15, 2026
48 checks passed

mydea deleted the fix/amqplib-v1-flaky-transaction-order branch June 15, 2026 13:23

sentry-release-botBot mentioned this pull request Jun 19, 2026
publish: getsentry/sentry-javascript@10.59.0 getsentry/publish#8636
Closed
48 tasks

github-actionsBot mentioned this pull request Jun 19, 2026
[Flaky CI]: Node (18) Integration Tests - suites/tracing/amqplib-v1/test.ts > amqplib v1 auto-instrumentation > esm/cjs > esm > should be able to send and receive messages with amqplib v1 #21173
Closed