Two teardown tests are duplicated across repos and drifted: #3291 updated core's copies only (not a regression) #3345

Activity

1. rbuergi commented on Sep 5, 2026

   

   rbuergi

   on Sep 5, 2026

   ContributorAuthor

   More actions

   Corrected: this is not a regression. The title is wrong and so was my root cause.

   I narrowed the bisect to a single commit and it refuted the premise. Nothing in #3291 broke a
   behaviour. What broke is that these two tests exist twice, and #3291 updated one copy.

   The bisect, exact

   The Plugins test project was held constant; only MeshWeaverRoot varied across detached core
   worktrees. Filter: both test names, MeshWeaver.Hosting.Monolith.Test.

   core commit		result
   6163dfacb	#3291's branch point	2/2 pass
   f92305ae1	#3291, commit 1 of 5	0/2 fail
   46e6f7941	#3291, commit 2	fail
   ef42bed55	#3291, commit 3	fail
   7d644de95	the pin being replaced	2/2 pass
   d99165850	the pin being taken	0/2 fail

   So the entire delta is f92305ae1 — "Teardown lets accepted work finish and names what it had to
   stop — no forced teardown" — the maintainer directive of 2026-09-04. One commit, not a merge.

   Why it looked like a product regression

   NackReachesTheWaiterDuringTeardownTest and LateNackReenqueueTest live in both repos:
   test/MeshWeaver.Graph.Test/ here, and MeshWeaver.Plugins/src/MeshWeaver.Hosting.Monolith.Test/
   where a monolith mesh can actually be stood up. Core's copies carry the note "Core twin of … Keep
   the two in step." f92305ae1 rewrote core's copies to the new contract and left the Plugins
   originals asserting the contract it had just deleted.

   The divergence is one clause. Core's parked turn releases itself when the owner starts shutting
   down:

   SpinWait.SpinUntil(() => Volatile.Read(ref releaseGate) == 1 || owner.IsShuttingDown, …)

   The Plugins copy waited only for the test's own finally. With the 8 s force-teardown deleted, a
   turn blind to the shutdown holds the owner at DisposeHostedHubs — honestly pending — and the
   caller burns its verdict budget, which is the VERDICT_TIMEOUT in the log. Core's rewritten copy
   predicts this exact failure in prose; nothing measured it.

   The fix, and the control

   In Systemorph/MeshWeaver.Plugins#1359 (the pin bump, where it belongs — the guard below compares
   against MW_PLATFORM_REF, so it can only be green once the pin moves):

   1. Both bodies ported verbatim from core at d99165850; namespace and header comment are the only
      edits. They pass at both pins — the release-on-shutdown turn needs no watchdog either way —
      so this was never pin-gated, it was just stale.
   2. TeardownTwinParityTest — the control the comment was standing in for. It compares each body
      below the namespace line against the core checkout at the pin, never core's main, so it
      reddens only in the change that MOVES the pin, which is the change that owes the update. A
      missing platform checkout fails rather than skips.

   Verified it discriminates rather than merely passing: 4/4 at d99165850; at 7d644de95 the two
   parity theories fail, naming the file, the line and both sides.

   What this says about the guard surface

   This is break shape 7
   — behaviour changing behind an unchanged signature — with a twist worth recording: the dependent
   held a duplicated test asserting the old behaviour. No surface detector can see it, the
   cross-repo pair gate has nothing to resolve, and the symptom surfaces in an unrelated-looking suite
   one pin bump later. The marker that was supposed to prevent it was a comment, and it sat on the copy
   whose editor already knew. I will carry that into CrossRepoPairGate.md here.

   Closing when #1359 merges.
2. rbuergi

   changed the title [-]Regression: a disposing owner stops answering its waiter — #3291 breaks two long-standing Nack/teardown tests, bisected[/-] [+]Two teardown tests are duplicated across repos and drifted: #3291 updated core's copies only (not a regression)[/+] on Sep 5, 2026
3. rbuergi commented on Sep 5, 2026

   

   rbuergi

   on Sep 5, 2026

   ContributorAuthor

   More actions

   Closed — twins synced, and all four portal-host shards are green on main

   Not a regression, as the corrected title says. The two tests exist in both repos because core's
   CI cannot stand up a monolith mesh; #3291 rewrote core's copies to the no-forced-teardown contract
   and left the Plugins originals asserting the contract it had just deleted. The bisect, with the test
   project held constant and only MeshWeaverRoot varying, put the entire delta on one commit:

   core commit		result
   6163dfacb	#3291's branch point	2/2 pass
   f92305ae1	#3291, commit 1 of 5	0/2 fail

   One clause: core's parked turn releases itself on || owner.IsShuttingDown; the Plugins copy waited
   for the test's own finally. With the 8 s force-teardown deleted, a turn blind to the shutdown holds
   the owner at DisposeHostedHubs — honestly pending — and the caller burns its verdict budget.

   Landed:

   • Plugins#1363 — bodies ported verbatim from core. Split out deliberately: they pass at both
     pins, so they were never pin-gated, and the stale copies were reddening live PRs (An install can be torn down by DisposeHostedHubs two seconds in, writing 0 nodes — disposal does not wait for work in flight #1360 lost
     Portal hosts (shard 2) to exactly this 10 s TimeoutException). All four shards are green on
     Plugins main now.
   • Core The core twins name the guard that enforces them; shape 7's worst form is written down (#3345) #3346 — both core twins carry a marker pointing at the guard, and
     Doc/Architecture/CrossRepoPairGate gains "Shape 7's worst form: the dependent holds a COPY of the
     test".
   • Plugins#1359 — TeardownTwinParityTest, the control the comment was standing in for. It
     compares each body below the namespace line against the core checkout at MW_PLATFORM_REF,
     so it reddens only in the change that moves the pin — the change that owes the update. A missing
     platform checkout fails rather than skips. Verified it discriminates: 4/4 at the current pin,
     and at the previous pin both parity theories fail naming the file, the line and both sides.

   The lesson worth keeping

   The marker was one-sided. Core's copy said "keep the two in step"; the Plugins copy said nothing
   — so the note was addressed to the party who already knew, and the one who needed it never saw it.
   Prose that asks a future reader to keep two files in step only fires when someone is already looking
   at the right file. A duplicated test needs a parity guard, and the marker goes on both copies.
4. rbuergi

   closed this as completedon Sep 5, 2026