test(pg): check the Sentry layer-wrap premise against the real library

[lilyshen0722]

What this is

#1958's fix is pinned by two tests that hand-wrap an Express layer (wrapLikeSentry), because the unit tier cannot host real @sentry/node: under jest, OpenTelemetry's require-hook never patches express through jest's module registry, so handle === router stays true in-suite. So the suite pinned the FIX and never the PREMISE — if a Sentry upgrade stops exposing .stack on the wrapper, all 15 tests stay green while production goes back to refusing a pod that has the routes mounted.

This adds the premise, hosted where it can actually be true: a plain-node child process spawned from jest, which registers ts-node, runs real Sentry.init() before require('express'), and reports the shape of the wrapping as JSON. The child process is the only way to host this inside the tier that already runs pre-merge — jest's module registry is precisely what prevents the patch.

Files

• backend/__tests__/utils/sentryLayerWrapProbe.js — the child. Builds app A (the pg router at /api/pg/messages plus another at /api/other) and a foreign app B (only /api/other); reports wrapped, handleName, handleHasStack, foreignWrapped, self, unmounted, foreign; always exits 0, so a crash reads as "no result + stderr" rather than an opaque status.
• backend/__tests__/unit/services/pgBootService.sentryWrap.test.js — spawns it twice, PROBE_SENTRY=1 and PROBE_SENTRY=0 as the positive control, via process.execPath, and asserts four things.

Measured (real @sentry/node 10.65.0, node v22.23.1)

• control → wrapped:false, handleName:"router", self:true
• instrumented → wrapped:true, handleName:"layerHandlePatched", handleHasStack:true
• main's pgBootService → 1 failed / 3 passed; the failure is the mounted-router case, so the P0 reproduces in-suite against main's code with no fakes
• with fix(pg): the readiness mount check sees a router Sentry has wrapped #1958's pgBootService → 4/4, and 19/19 together with pgBootService.test.js

The non-vacuity assertion is separate from the answer assertion on purpose. self:true is also what a Sentry version that stops wrapping would produce, through the identity clause alone — a suite asserting only self would go green while the wrap clause became dead code, and a reader would be told the clause is load-bearing when it isn't. wrapped + handleHasStack separate "the clause works" from "the clause is unnecessary".

Held until now, and why

On main this suite is red by construction — main's pgBootService has no stack clause, which is the P0 it covers — so opening it would have put a red check in a queue whose press is not mine. It was pushed and held. #1958 merged at 11:27:00Z (ff8de0fa); this branch now has main merged in (merge commit, no rebase: it carries a human-attributed commit) and is 0 behind.

Verification

19/19 at the merged head, run with the worktree's local jest. A note for anyone reproducing: npx jest from the worktree root resolves an npx-cached jest and fails with a babel transform error that reads like a product failure — the green run above used ./backend/node_modules/.bin/jest.

jest --listTests | grep -c sentryLayerWrapProbe = 0, so the probe is not collected as a suite: it lives in __tests__/utils/, which testPathIgnorePatterns already excludes, avoiding the "your test suite must contain at least one test" trap the config's own comment describes. eslint clean on both files.

[lilyshen0722]

CODE GATE: PASS @ 3e7ce46a — sprint-review. 2 files / +233, author Lily. 19/19 confirmed by running the suites, not by taking the count: 4 premise cases + the 15 existing.

Correction to the PR's own claim: behind 1, not 0. Main moved to 2659760e9 (#1957) after the merge commit here. Harmless — #1957 touches backend/integrations/manifests.ts and connectors tests, disjoint from this PR's two files, and git merge-tree --write-tree against current main is clean. No rebase needed; the claim had just decayed.

The failure mode I went looking for

A probe that "always exits 0" plus a consumer that parses its stdout is the standard way a premise test stays green while measuring nothing. Reading describeProbe suggested that was handled; I checked instead of trusting it. Suppressing the probe's only process.stdout.write:

✕ control: with no instrumentation the layer handle IS the router…
✕ instrumentation really replaces the layer handle, so this suite is not vacuous
✕ answers true for a mounted router while instrumentation has wrapped its layer
✕ answers false for a router that is not mounted, and for one mounted on another app
  the probe produced no JSON result. [control] exit=0 signal=null stdout= stderr=

All four red, and the message names which child produced nothing. The design does not fail open.

The two directional mutants

mutation	result
probe reports out.wrapped = false	1 failed / 4 — …so this suite is not vacuous
pre-#1958 pgBootService.ts (wrap clause absent; grep -c = 0)	1 failed / 4 — answers true for a mounted router while instrumentation has wrapped its layer

RESTORED: 4/4, git diff --quiet clean.

The first of those is the one worth dwelling on. With wrapped forced false, self stayed true — the identity clause alone answers the question — and only the vacuity assertion reddened. That is exactly the scenario the file's header describes, so that assertion is load-bearing rather than decorative, and I now know it by measurement rather than by the comment claiming it.

And the two mutants fail in different directions, which the suite distinguishes. wrapped: false means "the clause has become vacuous and could be deleted." A missing clause under real wrapping means "production refuses a pod that serves chat." Most premise tests collapse those into a single undifferentiated red; this one separates them, and the failure messages carry the distinction. That is the part of this PR I would protect in review.

Also confirmed: the probe is not collected as a suite (jest --listTests | grep -c sentryLayerWrapProbe = 0), so the __tests__/utils/ placement does what its comment says. CI: 14 checks pass, 2 conditional main-guards skipping, nothing red or pending.

One non-blocking note

layerFor in the probe selects the layer with l.handle === target || (l.handle && l.handle.stack === target.stack) — the second clause being the property under test. So in the regression this file exists to catch, where a Sentry upgrade stops exposing .stack on the wrapper, the layer is simply not found: layerFound reddens first and handleHasStack never gets a chance to speak.

The regression is still caught, which is what matters, and I am not asking for a behaviour change. But the failure will read as "layer not found" when the cause is "the wrapper no longer exposes the router's stack", and the next person to see that red will spend time on the wrong hypothesis. A sentence in layerFor saying the selector deliberately shares the property under test, and that layerFound: false under sentry: true should be read as the premise having changed, would cost nothing and save that detour.