3 objectql tests fail on clean main: the analytics slot is populated where `plugin.step2` / `protocol-discovery` pin it empty (#3891 expectations)

[os-zhuang]

Hit while validating #4011 — reproduced on a clean checkout of main (d6bfb3d) with no local changes, so it is not that PR's doing. Filing per the drive-to-green convention so it doesn't get attributed to whoever touches @objectstack/objectql next.

Repro

pnpm --filter @objectstack/objectql exec vitest run src/plugin.step2.test.ts src/protocol-discovery.test.ts
# Test Files  2 failed (2) · Tests  3 failed | 21 passed (24)

The three failures

All the same shape — the tests pin the ADR-0076/#3891 ruling that the analytics service slot stays empty until service-analytics fills it, and something now fills (or fakes) it:

1. plugin.step2.test.ts › registerProtocol:false + MetadataProtocolPlugin reproduces the built-in service surface — expect(() => kernel.getService('analytics')).toThrow() → did not throw.
2. plugin.step2.test.ts › default assembly registers protocol but leaves the analytics slot empty (降级 analytics shim 把 ExecutionContext 丢在门口 —— /analytics/query 在没装 service-analytics 的装配里不注入 RLS/租户谓词，契约字段 where 也被静默忽略 #3891) — same assertion, same non-throw.
3. protocol-discovery.test.ts › should report analytics unavailable with no advertised route when not registered — discovery.services.analytics.enabled → true, expected false.

Reading

The test comments state the intent explicitly: "the slot stays EMPTY until service-analytics fills it … /analytics 404s honestly instead of answering with wrong numbers". Either a recent change legitimately made analytics self-register (in which case these three pins — and the honest-404 story they encode — need a deliberate revision, not a drive-by green-up), or something started stuffing the slot as a side effect and the tests are correctly catching it. Both readings need an owner who knows the #3891 intent; mechanically flipping the assertions would erase the ruling they exist to protect.

Likely candidates are whichever of the recent protocol/spec merges touched service assembly (the failures exist at d6bfb3d; I did not bisect further).

Not v17-blocking if the behaviour change was intentional — but worth deciding before the release, since "analytics answers with wrong numbers instead of 404ing honestly" was the exact bug #3891 fixed.

[os-zhuang]

Root-caused. Neither of the issue's two hypotheses is what happened — there is no code bug, and the tests are not catching a regression. The failures were a stale-dist artifact in the checkout that reported them. The "clean checkout of main with no local changes" premise was wrong in one specific, verifiable way: dist/ is gitignored, so git status being clean says nothing about whether the built artifacts match the sources.

Timeline (this is the crux)

commit	when (+0800)	what
77fadbf (#3989)	09:53	Retires the degraded analytics shim and adds the three pinning assertions, atomically, in the same commit
d6bfb3d (#3990)	10:09	The issue's repro commit — an unrelated spec refactor (rls.priority etc.); the only commit between them

So at d6bfb3d the sources were fully post-retirement — code and tests were never out of sync in git history. The tests and the behaviour they pin landed together and cannot disagree at any commit.

The mechanism

All three failures come from one stale artifact: packages/metadata-protocol/dist built from pre-77fadbf sources.

1. Both failing test files import from the package, not the sources: import { … } from '@objectstack/metadata-protocol' → resolves via "main": "dist/index.js" (no vitest alias in objectql).
2. ObjectQLPlugin's default assembly calls assembleMetadataProtocol from that same package. The pre-retirement version did ctx.registerService('analytics', { …status: 'degraded'… }) — so kernel.getService('analytics') doesn't throw → failures 1 and 2, exactly expected [Function] to throw an error.
3. The pre-retirement getDiscovery() hardcoded analytics: { enabled: true, route: '/api/v1/analytics', … } even with no services registry → failure 3, exactly expected true to be false.
4. The issue's repro command — pnpm --filter @objectstack/objectql exec vitest run … — does not rebuild dependencies, so it faithfully re-reads whatever dist is lying around.

Verification (both directions)

On a worktree at today's main (e4c61a7), fresh pnpm install + full pnpm build:

• Negative: vitest run src/plugin.step2.test.ts src/protocol-discovery.test.ts → 24/24 pass.
• Positive control: git checkout 77fadbf^ -- packages/metadata-protocol/src + rebuild only that package (simulating the stale dist), same command → 3 failed | 21 passed, with byte-identical failure signatures to this issue: expected [Function] to throw an error ×2, expected true to be false ×1. Restore + rebuild → 24/24 green again.

Corroboration: every recent full-suite push run on main (1ea6bce, 99b4392, 6f98c2d, 4580597, …) is green — and note the PR-side Test Core runs turbo run test --affected, so PRs not touching objectql never re-run these tests; only main pushes were probative, and they all pass.

Why the reporting session had a stale dist

That session's worktree had been built before 77fadbf landed; main was then fast-forwarded and the tests re-run without a rebuild. This repo's own dogfood-verification skill documents the trap ("packages load from dist, not src … editing has no runtime effect until you rebuild"), and the same session had already hit it once the same day (a --force rebuild for a runtime edit). The #3891 comments visible in the failing tests should have been the tell: assertions referencing the retirement were present, so the checkout's sources were post-retirement — only the artifacts weren't.

What (if anything) to change

Nothing in objectql/metadata-protocol — the #3891 ruling is intact, correctly enforced, and correctly pinned. The one cheap process guard worth considering: repro commands in issues should use pnpm turbo run test --filter=<pkg> (which rebuilds the dependency graph) rather than bare vitest run, precisely so a "fails on clean main" claim carries a fresh-artifact guarantee. Not filing that as its own issue — noting it here is enough.

Closing as not a bug. Verified date for the record: 2026-07-30, worktree /home/user/objectstack-4013 at e4c61a7.

---

Generated by Claude Code