No packages/sdk test runs in CI

[khaliqgant]

Every test file under packages/sdk is unrunnable in CI. This is not a single-file oversight — it is the whole package.

Evidence

• vitest.config.ts:78 excludes packages/sdk/** from the root suite. The stated reason is // Uses Node.js test runner, not vitest, which is stale: packages/sdk/src/messaging/placement.test.mts imports describe/expect/it/vi from vitest.

• packages/sdk/vitest.config.ts includes only src/__tests__/**/*.test.ts, so it would not pick that file up either.

• The package's own test script enumerates 14 files by name. There are 15 test files under packages/sdk/src; placement.test.mts is not one of the 14.

• Nothing invokes the package's test script. Every CI test step is root-level:

  • .github/workflows/test.yml:53 — npm test
  • .github/workflows/test.yml:77 — npm run test:coverage
  • .github/workflows/node-compat.yml:62 — npm test
  • .github/workflows/publish.yml:452 — npm test
  • .github/workflows/fleet-e2e.yml:105 — npm run test:e2e
  • .github/workflows/rust-ci.yml:38-40 — cargo test

  Root npm test is vitest run, with no --workspaces fan-out.

Net effect: all 15 SDK test files can pass, fail, or rot without CI ever noticing.

Why it surfaced

Found while adding requester-side spawn confirmation in #1431. The load-bearing regression tests for that fix were deliberately placed under packages/cli instead, because tests placed beside the code they cover would never have run. #1431 documents this in its body rather than working around it silently.

What needs deciding

Un-excluding packages/sdk/** will likely surface pre-existing failures, which is precisely why it should not ride along in an unrelated PR. Suggested order:

1. Run the SDK suite locally and record what currently fails.
2. Fix or explicitly skip those.
3. Remove the root exclusion (or add an SDK job that runs the package's own config), and correct the stale "Node.js test runner" comment.

Do the steps in that order. Un-excluding first would dump an unknown number of pre-existing failures onto whoever does it, and a change that turns CI red on arrival gets reverted rather than fixed. Record the current failure set first so the un-exclusion is a known, bounded step.

Filed without a readiness label so this does not dispatch.

---

Failure inventory (measured 2026-08-14)

The suite was run in full — all 15 files, via a temporary config including src/**/*.test.{ts,mts} — to size the hole before anyone tries to un-exclude it.

Result: 15 files / 183 tests → 12 failed, 171 passed. 2 files red.

File	Result
src/__tests__/thin-client.test.ts	6 of 10 failed
src/__tests__/agent-relay.test.ts	6 of 9 failed
the other 13 files	all passed

Failures are client-construction and channel-API assertion drift, e.g.:

AssertionError: expected "vi.fn()" to be called with arguments: [ 'Ops', …(1) ]
AssertionError: expected { apiKey: 'rk_live_test', …(6) } to deeply equal { apiKey: 'rk_live_test', …(1) }

The constructed client now carries ~6 properties where these tests assert 1–2. That is the signature of assertions that stopped matching the implementation and were never corrected, because nothing ever ran them.

These failures are pre-existing and unrelated to #1431. Control arm: the same two files were re-run with packages/sdk/src/messaging/{relaycast,types,relaycast-placement}.ts restored from origin/main — identical 12 failures. Nothing in #1431 causes them.

Note both red files are among the 14 enumerated in the package's own test script, so npm --prefix packages/sdk run test is red today too. The suite has not merely gone unrun by CI; it has already rotted.

This confirms the ordering above: un-excluding first would drop 12 unrelated failures on whoever does it. Fix or explicitly skip these two files first, then remove the exclusion.