fix(test): disable scheduling in passport test for CDS v10

[sjvans]

Problem

The HANA workflow's passport.test.js › gets set once for simple queries fails on cds-10-9 — see run 28586742752:

Message: expected 4 to strictly equal 2
> 41 |     expect(_count).to.equal(2)

Root cause

CDS v10 sets cds.requires.scheduling = true 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) + per-SELECT passport set (lib/tracing/trace.js:351).

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 ("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.

 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.

[hyperspace-pr-bot]

The change is correct and well-scoped. The environment variable name cds_requires_scheduling follows the standard CDS flat-key convention (underscore-delimited path of cds.requires.scheduling), it is set before cds is required so it takes effect at bootstrap time, and the comment accurately describes the root cause. No issues to flag.

The PR is a clean, minimal fix — a single targeted environment-variable override with a clear explanatory comment that prevents non-deterministic scheduler transactions from corrupting the _count assertions, without altering any production code.

PR Bot Information

Version: 1.26.14

• Correlation ID: 97eee740-76c4-11f1-9d9c-a2df1c241ad2
• File Content Strategy: Full file content
• LLM: anthropic--claude-4.6-sonnet
• Event Trigger: pull_request.opened

[hyperspace-pr-bot]

Summary

The following content is AI-generated and provides a summary of the pull request:

---

fix(test): Disable Scheduling in Passport Test for CDS v10 Compatibility

Bug Fix

🐛 Fixed a flaky test failure in passport.test.js caused by CDS v10 enabling scheduling by default. The scheduler's periodic outbox reads run in their own database transactions, which trigger spurious SAP_PASSPORT set/reset pairs on the connection, breaking the deterministic _count assertions in the test.

In CDS v9, each user request ran in a single transaction, so a simple query would produce exactly 2 passport operations (1 reset + 1 set). In CDS v10, the background scheduler introduces additional transactions that overlap with request timing, inflating the count to 4 and causing the assertion expect(_count).to.equal(2) to fail.

Changes

• test/passport.test.js: Added process.env.cds_requires_scheduling = 'false' at the top of the test file to disable the CDS v10 scheduler for this test. The test's purpose is solely to verify SAP_PASSPORT stamping during a user request — background scheduler transactions are irrelevant to this check and only introduce non-deterministic passport operations.

Context

This is the same class of issue addressed in PR #435 for queue metrics. The passport test was overlooked during that fix. The scheduler's cds.outbox.Messages polling generates a BEGIN → SELECT sequence that resets and re-stamps the passport on the shared HANA connection, producing extra counts unrelated to the user request under test.

Note: A follow-up improvement (out of scope) would be to skip dbc.set when cds.context?.user?.id === 'privileged' to avoid stamping SAP_PASSPORT on internal scheduler/outbox transactions in production environments.

---

• 🔄 Regenerate and Update Summary
• ✏️ Insert as PR Description (deletes this comment)
• 🗑️ Delete comment

PR Bot Information

Version: 1.26.14

• GithubContextProvider: fix: adapt queue metrics to CDS v10 scheduling changes #435
• Output Template: Default Template
• Correlation ID: 97eee740-76c4-11f1-9d9c-a2df1c241ad2
• Summary Prompt: Default Prompt
• LLM: anthropic--claude-4.6-sonnet
• Event Trigger: pull_request.opened
• File Content Strategy: Full file content