test(server-utils): Remove hapi unit test that replicated SDK async-context logic by andreiborza · Pull Request #22100 · getsentry/sentry-javascript

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza · 2026-07-08T15:26:12Z

Removes the hapi unit test that stubbed the SDK's async context strategy to drive spans, which replicated SDK internals in the test layer. Per the review thread in #21885, we rely on the integration tests instead.

The orchestrion path is covered by the hapi node integration suite. hapi-utils.test.ts stays (pure metadata formatting, no async-context stubbing). The remaining unit-only assertions checked internal implementation details (setup only wrapping once when called twice, no span without an active span, accepting the ext handler as a tuple or an object) rather than the spans a user actually sees, so there was nothing meaningful to move into an integration test.

Ref: #21885 (comment)

…ontext logic The suite stubbed the SDK's async context strategy via `setAsyncContextStrategy` to drive spans, duplicating SDK internals in the test layer. The hapi node integration suite already covers the orchestrion path end to end. `hapi-utils.test.ts` (pure metadata formatting, no async-context stubbing) is kept. Co-Authored-By: Opus 4.8 <noreply@anthropic.com>

andreiborza requested a review from a team as a code owner July 8, 2026 15:26

andreiborza requested review from JPeer264, chargome, isaacs, logaretm, mydea and s1gr1d and removed request for a teamJuly 8, 2026 15:26

logaretm approved these changes Jul 8, 2026
View reviewed changes

andreiborza merged commit a758b82 into developJul 8, 2026
416 of 419 checks passed

andreiborza deleted the ab/remove-hapi-unit-test branch July 8, 2026 18:00

sentry-release-botBot mentioned this pull request Jul 10, 2026
publish: getsentry/sentry-javascript@10.65.0 getsentry/publish#8844
Closed
49 tasks