Repository navigation
mcpx: conformance TestMessagesClient fails in the Nix build — toplevel amd build is red on main #2696
Description
Found 2026-10-30 while verifying the amd NixOS toplevel build for PR #2684 (base commit 2aec81c): the mcpx package's check phase fails, so nix build .#nixosConfigurations.amd.config.system.build.toplevel cannot complete on current main.
Failing test (from the build log, pkgs/mcpx/package.nix check phase):
--- FAIL: TestMessagesClient (0.99s)
--- FAIL: TestMessagesClient/2026-07-28/messages/messages-resulttype-extension-values (0.00s)
messages_test.go:822: declares extensions it does not handle: map[elicitation:map[form:map[]] extensions:map[] roots:map[]]
FAIL github.com/dezren39/mcpx/internal/conformance 89.947s
All other packages shown in the same run passed (examples, adapter, api, artifacts, buildcheck, cache, catalog, cli, codegen, config, daemon, defaults, diagnose …). The failure is in the conformance suite for protocol version 2026-07-28: the client declares extensions (elicitation/form, extensions, roots) that the messages result-type check says it does not handle.
Impact: the amd toplevel does not build on main until this is fixed, which also blocks nixos-rebuild switch on the laptop. The mcpx derivation's source is only the pkgs/mcpx/ subtree (src = ./. in package.nix), so this is independent of any non-mcpx change.
Distinct from #290 (TestTerminateOrphanedSession flake).
Activity
dezren39 commentedon Oct 30, 2026
Agent note — picked up
dezren39 commentedon Oct 30, 2026
Agent note — investigation complete: already fixed on current main (queue task 3923)
Root cause: at the reported base 2aec81c,
TestMessagesClient/messages-resulttype-extension-valuestreated the mere presence of theextensionscapability key as a violation. The client deliberately declares an empty extensions map on modern connections (register CAP-11, #1918) — the failure output in this issue shows exactly that (extensions:map[], empty). So the guard, not the client, was wrong.Fix: commit 2b67d01 ("fix(mcpx): conformance guard accepts CAP-11 empty extensions declaration", for #2653) landed 2026-10-30 04:55 CDT — 19 minutes after the base commit this issue was verified against (2aec81c, 04:36 CDT) — scoping the guard to non-empty maps. It is an ancestor of current main.
Verified this pass on current main (e616aef):
go test ./internal/conformance/ -run TestMessagesClient -count=1— ok (full test, all revisions).So the mcpx check phase failure that blocked the amd toplevel build is gone from main; a fresh
nix build .#nixosConfigurations.amd.config.system.build.toplevelshould get past this test. (Unrelated: the conformance package still has the separate TestMatrix/authsplit failure tracked in #2695 — different test, different cause.)Closing as already-fixed.
dezren39 commentedon Oct 30, 2026
Verification follow-up (2026-10-30, at Drew's request): this closure's conclusion is now confirmed in the Nix build itself. The queue worker's evidence was a direct
go testpass, which is not the Nix check phase — the proof below replaces it.a0625480bc9e692243b384e0edcb5cc96bc4fa272b67d015("fix(mcpx): conformance guard accepts CAP-11 empty extensions declaration" —pkgs/mcpx/internal/conformance/messages_test.goonly) is an ancestor oforigin/main. It scopes the extensions guard to non-empty extension maps, which is exactly this issue's failure (messages-resulttype-extension-valuesdeclaring an empty extensions map).nixos/environment/default.nixcallPackagespkgs/mcpx/package.nix; drvzb1mx57bw9rdd3739ssbrrymczp39vrl-mcpx-0.1.0.drv) was realised withnix-store --realisefrom a clean worktree at a062548: build succeeds, the check phase ran, 47 packages ok, 0 FAIL in the daemon build log.nix build .#nixosConfigurations.amd.config.system.build.toplevel --no-linkfrom the same worktree: exit 0 (49 derivations built, 0 fetched); the resulting toplevel is realised and itsactivateis present.One nuance for the record: since
7250bae8(#2686),internal/conformancesits in package.nix'scheckExclude(the auth-split matrix desync), so the conformance suite does not currently run inside the Nix check phase at all. The evidence for the suite itself remains the directgo test ./internal/conformance/pass recorded at closure plus the2b67d015fix; #2686 tracks the exclusion. The Nix-build gate this issue blocked is green either way, so the closure stands.