UNATTRIBUTED: ReadPathStreamMintingTest.AnUncachedConfiguredReduce_MintsOneSyncHubPerCall counted +6 sync hubs for 5 calls on a diff that cannot reach MeshWeaver.Data (#4292 run 34823051999) #4300

ReadPathStreamMintingTest.AnUncachedConfiguredReduce_MintsOneSyncHubPerCall — UNATTRIBUTED failure: +6 sync hubs for 5 calls, on a diff that cannot reach MeshWeaver.Data

This is filed as an unattributed failure, not a flake (working agreement, 2026-09-14: a test failing on a diff that cannot reach it proves only that the diff did not cause it — not that the defect is nondeterministic).

Occurrence

No earlier occurrence is findable by search (in:comments,title,body for the test name returns only #3952, the PR that introduced the test). This is the first recorded one.

What the number says

The test takes LiveSyncHubs(host) (the count of sync/ hubs in the host's HostedHubsCollection), makes 5 uncached GetStream(reference, x => x.WithClientId(…)) calls, and reads the count again. HostedHubsCollection.GetHub(…, Always) constructs synchronously, so each of the 5 calls contributes exactly one hub at return. A +6 therefore means one sync/ hub was created on the host by something other than those five calls, inside the window between the two counts — a window of a few milliseconds in the failing run (baseline at 08:36:46.919, count at 08:36:46.932).

The test's own guard against a foreign hub is LongHeartbeat = 5 min ("so every hub counted is one this test caused"), which covers heartbeat resubscribes and nothing else.

The shape to look for — a deterministic one, not a re-run loop

Candidates for the foreign creation, each a real ordering rather than noise:

1. The precondition's stream registering after its first frame. await workspace.GetObservable<BusinessUnit>() … Match(x => x.Count > 0) completes when a frame arrives; if any part of that read's sync-hub creation lands on the host after the frame (a second hub the reduce mints on subscription, a partition/data-source stream created lazily on first reduce), the baseline is taken one low.
2. The client hub connecting. HubTestBase builds a client as well; a client-side subscription that mints a sync/ hub on the HOST (its initial data mirror) is not caused by this test and lands whenever the client's startup gets there — on a loaded CI runner, plausibly inside this window.
3. The class's previous test's stream still settling (tests in a class run sequentially, but a stream from ReadingTheSameReferenceRepeatedly_… or UnifiedUpdate_… may complete a late subscription on the shared fixture).

Each of these reproduces at 100% by inserting the ordering deliberately (e.g. delaying the client's first subscription until after the baseline, or taking the baseline before the precondition's frame). That is the falsification to run before this is touched; a re-run that goes green says nothing about which of the three it was.

Handling on #4292

Re-run of the failed jobs requested once, to unblock, with this issue as the record. Not added to known-flakes.json. A recurrence on any PR is a signal — append it here, do not re-run past it.