## Problem The HANA workflow's `passport.test.js › gets set once for simple queries` fails on `cds-10-9` — see [run 28586742752](https://github.com/cap-js/telemetry/actions/runs/28586742752): ``` Message: expected 4 to strictly equal 2 > 41 | expect(_count).to.equal(2) ``` ## Root cause CDS v10 sets [`cds.requires.scheduling = true`](055f112) by default. Its Scheduler polls `cds.outbox.Messages` in its own database transactions. Those extra transactions overlap request timing and each triggers this plugin's `BEGIN` reset ([lib/tracing/index.js:141-143](https://github.com/cap-js/telemetry/blob/cds-10-9/lib/tracing/index.js#L141-L143)) + per-SELECT passport set ([lib/tracing/trace.js:351](https://github.com/cap-js/telemetry/blob/cds-10-9/lib/tracing/trace.js#L351)). Reproduced locally on `cds-10-9` with `@sap/cds@10.0.3` + `@cap-js/hana@3.0.1`. Instrumented the plugin's `dbc.set()` and captured the exact sequence: ``` [0] '' (reset) ← BEGIN of scheduler outbox tick [1] 2A54482A03… ← SELECT cds.outbox.Messages [2] '' (reset) ← BEGIN of user request [3] 2A54482A03… ← SELECT AdminService.Books ``` 2 transactions × (1 reset + 1 passport) = `_count = 4`. The test's assertion of `2` was correct for CDS v9's single-transaction-per-request behavior — cds v10 broke that invariant. The queue-metrics plugin already needed adjusting for the same scheduling shift — see [#435](#435) ("adapt queue metrics to CDS v10 scheduling changes"). Passport was overlooked. ## Fix Disable `scheduling` for this test only. The test's purpose is to verify SAP_PASSPORT stamping during a user request; the scheduler is irrelevant to that check and its background transactions just produce non-deterministic extra sets. ```diff process.env.SAP_PASSPORT = 'true' +// CDS v10 enables scheduling by default; its periodic outbox reads run in +// their own transactions and cause spurious SAP_PASSPORT set/reset pairs on +// the connection, breaking the deterministic _count assertions below. +process.env.cds_requires_scheduling = 'false' ``` ## Verification Ran the CI-scoped subset (`CI=true HANA_DRIVER=hdb HANA_PROM=true npm test`) locally against the same HDI container / driver stack the workflow uses: ``` PASS test/passport.test.js PASS test/tracing-attributes.test.js (18.184 s) Test Suites: 2 passed, 2 total Tests: 7 passed, 7 total ``` ## Follow-up (out of scope for this PR) There's an underlying semantic issue: the passport plugin currently stamps SAP_PASSPORT on every database call, including scheduler/outbox internal transactions that have no user request to correlate to. That pollutes DSR passport traces on production HANA — worth a separate PR that skips `dbc.set` when `cds.context?.user?.id === 'privileged'` at both sites. --------- Co-authored-by: sjvans <sjvans@users.noreply.github.com>

Uh oh!

Commits

Commits on Jun 29, 2026

Commits on Jul 2, 2026

Commits on Jul 3, 2026