Space delete-cleanup wait sat below the delete operation's own 30s contract by rbuergi · Pull Request #898 · Systemorph/MeshWeaver

rbuergi · 2026-08-07T08:37:43Z

The flake, root-caused

SpaceMenuAndAccessTest.Space_ChildrenAreQueryable redded main's post-merge run (31160623759, shard 5) with two DeleteNodeRequest callbacks pending 10.3s at dispose — while the test's actual assertions had already passed.

The cleanup NodeFactory.DeleteNode(spaceId) is a recursive delete: it fans out a DeleteNodeRequest per descendant (the Overview child and the auto-minted creator _Access grant), and each fan-out activates that leaf's per-node hub — a cold start HandleDeleteNodeRequest itself documents as 5–45s on a loaded CI runner. The operation's own ceiling is MeshOperationOptions.Timeout = 30s. The test waited only the assertion default of 10s — an assertion budget below the operation's documented contract. On a saturated shard the delete completes normally a moment after the assertion gives up; locally (and in bulk) the suite runs 85/85 in 12s.

Fix: both cleanup waits in the class now wait to the operation's contract (Within(30s)), with the reasoning in a comment. This is not a widened bound to make a wedge pass — nothing wedges; the wait simply contradicted the operation's own defined ceiling (the callbacks were observed live at 10.3s, inside the 30s budget).

Test-only change — no What's New entry.

Verification

MeshWeaver.NodeOperations.Test 85/85 in bulk (Release, one process)
Release -warnaserror build clean

🤖 Generated with Claude Code

…ntract Space_ChildrenAreQueryable (and its sibling) awaited the recursive space delete with the assertion default of 10s. The delete fans out a DeleteNodeRequest per descendant — the Overview child and the creator _Access grant — and each fan-out ACTIVATES that leaf's per-node hub, a documented 5-45s cold start on a loaded CI shard; the operation's own ceiling is MeshOperationOptions.Timeout (30s). So on a saturated shard the delete completed normally just past the 10s assertion: CI dumped both leaf callbacks pending at 10.3s, the test's actual assertions had already passed, and locally the whole suite runs 85/85 in 12s. Waiting below the operation's contract was the red — the wait now matches the 30s contract. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Copilot

Pull request overview

This PR adjusts SpaceMenuAndAccessTest cleanup waits so the recursive DeleteNode cleanup does not time out under the stream-assertion default (10s) when the underlying delete pipeline is bounded by MeshOperationOptions.Timeout (30s), addressing a CI-only teardown flake.

Changes:

Updated two NodeFactory.DeleteNode(spaceId) cleanup assertions to wait within 30.Seconds() before expecting an emission.
Added inline comments explaining why the longer wait matches the delete operation’s contract and avoids dispose-time pending callbacks.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

+        // The recursive delete fans out a DeleteNodeRequest per descendant (here: the creator
+        // _Access grant), each ACTIVATING that leaf's per-node hub — 5-45s cold start on a loaded
+        // CI shard (HandleDeleteNodeRequest). The operation's own ceiling is
+        // MeshOperationOptions.Timeout (30s); waiting only the 10s assertion default sat BELOW the
+        // operation's contract and was the shard-5 red on otherwise-green runs.
+        await NodeFactory.DeleteNode(spaceId).Should().Within(30.Seconds()).Emit();


github-actions · 2026-08-07T08:53:42Z