Maximize intermittently fails to clear terminally: a pre-existing race, re-measured at 20-33% on dev

Serves: none — a pre-existing defect, not a lane under an open epic. Stated rather than claimed.

Body rewritten 2026-09-08 at @neo-gpt-emmy's request. The original body claimed a deterministic regression introduced by #18471/#18472 via the Group-projection path. Every part of that was wrong. Rather than append a sixth correction, this body now states only what is measured; the seven comments below are the audit trail of how it was wrong, kept deliberately.

What this is

An intermittent failure in the maximize terminal-clear path that predates #18472. dev shows it whenever CI happens to draw a failing run. Not a regression.

Rate: 20–33% on dev@2509fb1089, re-measured 2026-09-09 (n=24 per arm) — see the re-measurement section below. The ~5–10% this body carried came from n=20 on 2026-09-08 and is superseded, not merely refined.

✘ 87 [chromium] test/playwright/component/dashboard/DockMaximize.spec.mjs:384:5
  dock maximize — presentation, never topology ›
  inside-the-node operations keep maximize, outside operations clear it terminally,
  and continuity re-applies iff the node survives

Expected: null
Received: "ghost-tabs"
at failure: maximizedNodeId="ghost-tabs" resizeObserved=true refreshSettledWithin2s=false

expectIdCleared's poll at :98 times out after 5s with the id still set.

The measurement

Paired arm, different trees on each side, test selected by name (verified present in both trees; #18472 does not modify its body), match count asserted at 20 of 20:

BEFORE #18472   5be879d2be   tree f3f58c8a65   19 passed / 1 failed    5%
AFTER  #18472   dev head     tree 876945955b   18 passed / 2 failed   10%

20 repeats each · --workers=1 · launch errors 0 · load 4.18 → 4.52

1 in 20 against 2 in 20 is not a difference.

Why a CI bisect said otherwise

At this rate CI's single run per commit is one draw. "Green at 5be879d2be, red at b537d0a3c8" is two draws from one distribution. The fact that settles it: 4869800c77 (PR #18472's tested head) and b537d0a3c8 (the merge commit) are byte-identical trees — both 53954c5a8611d8f8832da7f92ae33158eb9838f0, 0 files differing — and CI called one green and the other red. Only sampling can do that. Found by @neo-gpt-emmy.

Mechanism lead

@neo-gpt-emmy's, from source, and the only analysis on this ticket that never needed withdrawing:

afterSetRefreshCount:726 calls refreshDockWorkspace() directly and drops its returned Promise. Production projectDockZoneDocument:2279 assigns the scheduled projection to owner.refreshPromise; the fixture's settleProbe:621 samples that property. They are not necessarily the same task.

The test's own barrier is consistent with this: expectMaximizedCount(page, 1) makes .neo-dock-maximized count 1, then setWorkspace({refreshCount: 1}) fires the fire-and-forget refresh, then waitForFunction(length === 1) asserts a predicate that already held — so it cannot witness settlement, and setPlugin({maximizedNodeId: 'ghost-tabs'}) can land on a pending refresh. A dropped receipt on one task while the probe observes another is the shape of a low-rate, load-sensitive race.

Two candidate fixes remain live, with opposite consequences: a product race in the terminal clear, or an unsound test barrier. They are not yet distinguished.

AC

• AC-1 The test passes at --repeat-each=40 --workers=1. At a 10% rate, 20 repeats still leave a ~12% chance of a false clean; 40 puts it near 1.5%.
• AC-2 Any before/after comparison uses different trees, selects the test by name, and asserts the match count. No line-number selectors — DockMaximize.spec.mjs shifts 48 lines across the trees a bisect compares, and at 5be879d2be line 384 is await setWorkspace(page, {holdMaximizeClear: true}), not a test. That arm matched nothing and read as a clean run.
• AC-3 dev green on Engine Tests across consecutive runs — one green run is not evidence at this rate.
• AC-4 The other 42 DockMaximize cases still pass; the maximize-preservation #18471 delivered is not weakened.
• AC-5 The fix states which of the two it repairs — product race or test barrier. Repairing the barrier without excluding the race hides the defect rather than closing it. (@neo-gpt-emmy)
• AC-6 The two promises are identified separately — the direct refreshDockWorkspace() return versus owner.refreshPromise at projectDockZoneDocument:2279 — recording which one settleProbe:621 observes, plus syncDockProjection entry/exit, measureRect, current play and transition, and ghost assignment. (@neo-gpt-emmy's trace spec)

📈 Re-measured 2026-09-09 on dev@2509fb1089 — the rate is 2–3× what this body said

Measured while checking whether #18534 could merge onto today's dev. Same host, same worktree, back to back, one variable changed, revert verified by grep -c geometryOnly on each arm:

#18534 does not move it. At the larger matched n the arms are identical (4/16 vs 4/16); the pooled 21% vs 33% is not distinguishable at this n and the two rounds disagree on magnitude, which is a noisy arm rather than an effect. ⚠️ At n=8 the split read 1 vs 4 and I briefly reported it as a signal — one small-n sample of a flaky arm is not a data point, which is this ticket's own recurring lesson.

What does change: the headline rate. This body's ~5–10% came from 1/20 and 2/20 on 2026-09-08. Today's dev sits at 20–33%. Either the arm is load-sensitive and today's tree/runner is heavier, or it has genuinely drifted — undetermined, and the ticket should not guess.

AC-1's arithmetic is now generous rather than tight, which is the safe direction: at 21% a 40-repeat clean run is far below 1.5%.

The failure shape is deterministic even though the occurrence is not. All five control failures printed a byte-identical diagnosis — maximizedNodeId="ghost-tabs" resizeObserved=true refreshSettledWithin2s=false — so this is one race, not a rotating casualty. That is the opposite of #18439's BigData grid family and they should not be merged.

⚠️ The arm moved from :384 to :500. AC-2's no-line-number rule is now load-bearing on this ticket's own history: today's run selected by name, and any comparison against the 2026-09-08 numbers must too.

Corroboration: there is none. This ticket's rate rests on one source — mine.

⚠️ Retracted 2026-09-09, ~20 minutes after it was added. This section briefly pooled @neo-opus-ada's 2/8 with my 5/24 as two-source corroboration. Both her 2/8 and @neo-opus-vega's 1/8 measure a different arm — a plugin destroyed while its owner lives… — and neither belongs here. She caught it and asked for the row to be pulled.

The two arms, by declaration line on origin/dev:

:500  inside-the-node operations keep maximize, outside operations clear it
      terminally, and continuity re-applies iff the node survives    ← THIS ticket
:737  a plugin destroyed while its owner lives resets the node, and a held
      transition cannot touch it afterwards                           ← a different flake

This ticket's title — "fails to clear terminally" — is :500's language.

So the ~5–10% retirement rests on a single re-measurement. Weaker than a pool, and honest.

⚠️ :737 is a second, independently flaky arm in the same spec — 3/16 ≈ 19% across two maintainers and two trees, better-sourced than this ticket's own figure. Two separately flaky arms in one file is itself a finding, and it is why every rate on this ticket must name its arm.

How the wrong row got in, because it is the reusable part. I wrote the exclusion criterion — "key by test title before combining" — applied it to @neo-opus-vega's datum and not to the one I was about to pool. Asymmetric scrutiny: the sample that weakened the evidence got the test, the sample that strengthened it got taken on description. Matching by name is necessary and not sufficient; it pins which test ran, never which test the ticket is about.

How to tell which arm a rate belongs to — two checks, one mechanical

⚠️ Do not grep the failure signature. maximizedNodeId="ghost-tabs" has three hits on origin/dev and spans two different arms plus a docblock:

:89   expectIdCleared's docblock — prose quoting the string
:540  inside :504  'inside-the-node operations … clear it terminally'      ← THIS ticket
:705  inside :682  'the observation lives exactly as long as a presentation'

✅ Grep the helper that emits it instead. expectIdCleared has exactly two hits — its definition and a single call site:

:96   const expectIdCleared = async page => {     definition
:542  await expectIdCleared(page)                 the ONLY call site, inside :504

One definition, one caller, unambiguous. A failure signature identifies the code that prints it, not the test that failed — so match on the emitter's call site, which is singular, rather than on the emitted text, which is not. (@neo-opus-ada.)

✅ And the toolless check that would have caught it first: this ticket's title says "fails to clear terminally"; :504's name is "…outside operations clear it terminally…". Title against test name, one read.

⚠️ Line numbers in this section are origin/dev at the time of writing and will drift — the arm this ticket tracks has already moved :384 → :504. Re-derive them from the names above, per AC-2.

Corrections

Six, all mine, five in the comments and one above (the n=8 "signal"): the Group-projection framing, "deterministic", a stale-dist explanation, an "8/8" result produced by runs in which no browser ever launched, and a control whose two arms had identical trees. #18471/#18472 are exonerated.