Repository navigation
mcpx: e2e/examples cluster fails with 'may be destructive and was not confirmed' under the PR #2888 sharded suite — main's suite state is masked by #2795 #2896
Description
Evidence (found by queue task 3294, lane C, 2026-10-31)
PR #2888 (the #1998 first measured CI iteration: new mcpx-test.yml, workflow-only diff) run 41152763644 on head 52d9466f3:
- init PASS, lint PASS
- unit FAIL:
TestExamples/discoverandTestExamples/stateful—demo.structured/demo.open may be destructive and was not confirmed: nobody answered within 45s(plus the known pre-existing conformance/defaults/settings failures, mcpx: internal/settings tests red on clean main — TESTING.md missing from compendium manifest, model.* settings lack effect probes, env doc drift #2846 family) - ALL 6 e2e shards FAIL, with a recurring cluster:
TestAScriptsQuestionsReachAModernClientAsInputRequired,TestAScriptsQuestionsReachALegacyStdioClient,TestMcpxCallJSONCarriesTheDiagnostics,TestARequestStateOnAnotherRequestIsRefused,TestPassthroughToolQuestionsReachTheClient,TestMcpxCallPrintsTheDiagnostic— errors of the form<tool> may be destructive and was not confirmed: nobody answered within 45s/the answer was cancel.
Why main cannot currently arbitrate
mcpx.yml's go test ./... job is push-only, and every recent main push run (e.g. 41152450893, 41149248602) fails at the dogfood plugin-copy sync step (#2795) BEFORE go test runs — so there is no recent clean-main full-suite result to compare against. The failures may be (a) a real confirmation/elicitation regression on main that the push-only suite has been masking, or (b) an artifact of running e2e subsets via -run in shards (test-order/shared-state assumptions), or (c) a workflow-environment difference vs mcpx.yml (runtimes and working directory were checked and match).
Acceptance
- Reproduce one failing test (e.g.
TestExamples/statefulorTestAScriptsQuestionsReachALegacyStdioClient) under mcpx.yml full-suite conditions on clean main (once mcpx: dogfood .opencode plugin copy drifted again (ops.gen.ts adapters ops + instructions.test.ts missing) — sync guard runs push-only, so it now fails main and skips the whole mcpx test job #2795 unblocks it, or locally on the laptop) and record which of (a)/(b)/(c) holds. - If (a): fix the confirmation regression or file per-test follow-ups with the root cause.
- If (b)/(c): record the shard-safety constraint in
pkgs/mcpxTESTING docs and adjust ci(mcpx): first measured iteration — static e2e shards + unit + lint + ci-ok (#1998) #2888's workflow accordingly. - Do not silence by skipping: the cluster is the signal mcpx testing: first CI iteration -- unit + e2e shards + lint + nix build, and a recorded baseline #1998 exists to surface.
Activity
dezren39 commentedon Oct 31, 2026
Intake review
🤖 Agent note · filed
Still live: yes — PR #2888 is open and the masking condition (#2795 blocking main's full suite) is named in the body; no merged PR resolves this.
Related: #1998 (the sharded-suite work that surfaced the cluster), #2795 (dogfood sync failure masking main's suite), #2846 (known pre-existing failures family), PR #2888.
Notes / risks: until one failing test is reproduced under full-suite conditions, (a) regression vs (b) shard artifact vs (c) environment stays undecided — every other mcpx CI conclusion is provisional while main has no clean full-suite result.
Suggested approach: follow the body's own Acceptance order — reproduce one test on clean main under mcpx.yml conditions first; only then fix or document shard constraints.
Labels normalized:
kind/ci,priority/high(main's suite state is currently unknowable, which masks everything else),effort/m,status/needs-triage,meta/enriched.dezren39 commentedon Oct 31, 2026
agent-note:v1 — reproduced (a): real main regression, bisected to bd48deb (#2829)
repo-health-code-pilotVerdict: (a) a confirmation regression on main — not a shard artifact, not an environment difference
Reproduced locally on the laptop, single test, no sharding:
TestAScriptsQuestionsReachALegacyStdioClientorigin/main@ d72c889ask.need_repo may be destructive and was not confirmed: the answer was cancelf318fd595(bd48deb^)origin/main+MCPX_POLICY_WRITE=allowgit log --oneline origin/main -- pkgs/mcpx/internal/daemon/consumer.go— the last change isbd48deb1e mcpx: write policy gate (policy.write ask/allow/deny) — #1979 Phase 1 (#2829). The test passes on its parent and fails on it."writePolicy": "ask"tointernal/defaults/defaults.json(consumer block). Every tool whose schema carries noreadOnlyHint: trueis then a write by the specification's defaults, so the gate opens a confirmation on every such call. The e2e harness's fake/ask servers either cannot answer or answercancel, and the gate reads that as a refusal — hencethe answer was canceland, where nobody is listening,nobody answered within 45safter the 45s AskTimeout (which is why the affected tests each take ~45s).examples(TestExamples/discover,TestExamples/stateful) — every unannotated tool call. That matches the PR ci(mcpx): first measured iteration — static e2e shards + unit + lint + ci-ok (#1998) #2888 run: all 6 shards red with the same signature.handoff_load_test.gosetspolicy.write=allow"since their raw clients cannot answer questions"). The same reasoning applies to ~40 other e2e tests, which were not updated — so main has been red for mcpx e2e since that merge.Suggested fix (test-side, no policy decision needed) — pick one
MCPX_POLICY_WRITE=allowinnewEnv's env list besideMCPX_AUTOSTART_IDLE_EXIT, exactly as mcpx: write policy gate (policy.write ask/allow/deny) — #1979 Phase 1 #2829 did for the handoff tests; the gate's own tests (internal/daemon/write_policy_test.go,TestConfirmDestructiveHoldsOnAColdDaemon, the cold-catalog confirm test) opt back in toask. This restores main without touching the default.handoff_load_test.goalready does.ask-by-default is not the intended product behaviour, revisit the default itself — but that is Design: mcpx write policy — one gate for writes (ask/allow/deny, argument rules, unknown-outcome ledger) #2126/mcpx: a write policy -- ask, allow, deny -- with the exact call shown when asking #1979's decision, not this issue's.Also confirmed pre-existing on clean main (same run, unrelated to this cluster)
TestNoPackageRedeclaresADefaultfails onorigin/main@ d72c889 with the same settings/defaults family in #2846 — the unit leg's six guard failures are not #2888's.Effect on PR #2888
#2888 is workflow-only; with this bisect its red legs are fully attributed to main, not to the diff. It stays parked until this lands, then re-runs and merges. Evidence posted on #1998.
fix(mcpx): interim-exclude examples from the sandbox check phase (#2896)
dezren39 commentedon Oct 31, 2026
🤖 Agent note · reproduction result (from queue task 4303, lane F)
This issue's acceptance asks which of (a) real main regression / (b) shard artifact / (c) workflow-env difference holds. Evidence for (a):
On a clean-main laptop worktree (94fdb0f), single test, no sharding, no CI:
go test ./internal/e2e/ -run TestExecSurfacesToolErrorsAsExceptions -count=1→ FAIL (45s):demo.boom may be destructive and was not confirmed: nobody answered within 45s(e2e_test.go:302) — the identical signature as PR #2888 run 41167114746's shards.So the cluster reproduces locally on clean main under full-suite-style conditions; it is not produced by
-runsharding or by the GitHub runner environment. Full diagnosis table (unit + e2e families of PR #2888) is recorded on #1998.Merge pull request #2943 from developing-today/queue/2896-mcpx-e2e-po…