9838f42076
Core 32 failures -> 0 (5,981 passing); CLI 46 -> 0 (2,021 passing). Three agents per package, root-cause fixes only. One product defect, same class as FN-9059 and found the same way — by a test that leaked state between runs: `projectTableNames` was missing SEVENTEEN tables the schema declares (current_plan_evidence, spec_locks, spec_drift_reports, symbol_locks, configuration_revisions, chat_tags, chat_session_tags, mission_lineage_stops, task_verification_requests, unplanned_execution_blocks, workflow_agent_capacity_leases and the six task_lifecycle_* tables). That list drives BOTH the PG test-harness per-test reset and production health compaction, so those tables were never truncated between tests (a plan-evidence version counter carried forward, making whole-file runs disagree with isolated ones) and never VACUUM/ANALYZEd in production. Registered, with project-table-registry.test.ts as a ratchet — verified it fails on an unregistered new table naming the offender. Everything else was drift behind deliberate changes: branch-write provenance, FN-073 dependency validation, the FN-9191 pre-merge merge gate, U11's triage/ planning lane merge, refinement workflow coming from the ORIGIN selection, async-converted provider registration, a barrel mock missing exports a guard added, and several source-pinned inventories broken by module moves. Tests for removed features were deleted with their removing commit cited. Also fixes a vitest config gap where @fusion/core/mcp-builtin-servers resolved only to dist/, which was breaking test COLLECTION in unrelated CLI files and had been misread as transient cross-agent noise. Quarantines mission-store.pg's concurrent-claim race (second sighting): it holds a transaction open, sleeps 250ms and asserts the rival has not settled, which fails under parallel load. An A/B against the registry change above looked causal on one run and did not reproduce on three — that coincidence is the flake itself, and rescue needs a real lock-wait probe rather than a longer sleep. Core's config now inlines its exclude array, because check-quarantine-ledger.mjs cannot resolve a variable reference and silently reported the ledger unpaired. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
2.6 KiB
JSON
16 lines
2.6 KiB
JSON
{
|
|
"$comment": "Flaky-test quarantine ledger (deletion ratchet \u2014 see AGENTS.md 'Flaky tests: quarantine on sight' and docs/testing.md 'Quarantine ledger and the deletion ratchet'). A test observed failing without a corresponding real bug is quarantined ON SIGHT: add an entry here AND a matching one-line `exclude` entry in that package's vitest config, in the same commit. Every entry needs a non-empty `reason` (link the failing run) and a `quarantinedAt` date \u2014 the entry expires 14 days later, at which point the test file is DELETED unless someone rescues it with evidence it catches real regressions plus a root-cause fix (never appeasement). scripts/check-quarantine-ledger.mjs mechanically verifies this ledger and concrete `exclude:` array entries stay in lockstep.",
|
|
"entries": [
|
|
{
|
|
"file": "packages/engine/src/__tests__/self-healing-pending-wedge-notification.test.ts",
|
|
"reason": "SECOND sighting of a suite-only flake: 'reconcile pending wedge notifications > selects elapsed markers and audits the completion outcome verbatim' fails ONLY in a full engine-suite run (expected 1 selected marker, saw 2) and passes deterministically in isolation and in small multi-file runs. First sighting was recorded in docs/solutions/test-failures/suite-only-flakes-observed-register.md at ea48af7ab5; observed again on the full run at a97aa84a20. Reads as cross-test state bleed into the reconciler's marker selection, not a timing wait \u2014 no timeout, retry, or assertion was changed. Per AGENTS.md the second sighting is an on-sight quarantine with no further discretion.",
|
|
"quarantinedAt": "2026-08-23"
|
|
},
|
|
{
|
|
"file": "packages/core/src/__tests__/postgres/mission-store.pg.test.ts",
|
|
"reason": "Load-sensitive wall-clock race: 'serializes concurrent claims on the same task (Greptile P1 race)' holds a transaction open, sleeps 250ms, then asserts the competing claim has not settled. Under parallel machine load the second claimant settles (its `settled` flag flips on EITHER success or failure), so the assertion fails with no serialization bug. Observed twice on 2026-08-23 while three dashboard suites ran concurrently (a subagent's 180-file core run, then a full-core run plus an isolated run); passes 65/65 three consecutive times once the machine is calmer. An A/B against the projectTableNames registry change looked causal on one run and did NOT reproduce - the coincidence is the flake itself. Rescue needs a deterministic block-detection signal (e.g. pg_locks / a lock-wait probe) instead of a sleep, not a longer sleep.",
|
|
"quarantinedAt": "2026-08-23"
|
|
}
|
|
]
|
|
}
|