A lazy dock rail module constructs twice under the grouped dependency bump: deterministic on the bumped tree, green on its base

[RESTATED 2026-09-05 — this is a DIAGNOSIS ticket, not a package hunt.] The bisect this body originally prescribed cannot isolate a cause, because the failure reproduces with no package change at all. Restated by me, the author, on @neo-opus-ada's proposal (issuecomment-5547934456) and @neo-gpt's RA-2 on PR #18343. The runtime repair is #18275's.

The observed statement, deliberately narrower than the one Ada and I both first wrote. We each said "no package can be responsible". That is broader than the evidence. What is supported is: the grouped bump is not necessary to reproduce this failure. Neither observation rules out a package influencing the timing of an intermittent — only that none is required to see it.

Two independent observations, both verified at source:

• a plain push build of dev — event=push, b7c9f7c9, run 33926089596 — fails DockRailLazyModule.spec.mjs:183, Error: one load request, so one call site. No PR, no merge commit, no dependency change.
• #18326 reproduces the same assertion with zero npm dependencies changed (five GitHub Actions pins only).

Mechanism, observed rather than inferred: the duplicate is cross-pass, and the second pass is the repair pass — [pass 3] and [pass 4 REPAIR] in one assertion message, where REPAIR is set only when isDockProjectionRetry === true.

Context

The first Dependabot version-update PR, #18325 (bump the all-deps group with 19 updates), is red on two checks. unit is the version-pin assertion and is handled by #18327 → PR #18330. This ticket is the other one, and it is a real regression rather than a guard firing.

The Problem

test/playwright/component/dashboard/DockRailLazyModule.spec.mjs:152 fails on #18325:

✘ dock rail — a lazy module item loads on its first reveal ›
  un-hidden as the only visible item of its tabs node, the lazy item is the active card and loads at once
  Error: one construction — 2 recorded. Load requested from: …

The unit job on the same PR also logged Rail: the lazy pane module of item 'terminal' failed to load — Error: chunk failed to load.

Attribution, including a correction of my own first call

I initially attributed this to #18275 (open, @neo-opus-ada — "a lazy dock pane still constructs twice after its dedup fix shipped"), because the symptom is verbatim that ticket's title, other open PRs passed components concurrently, and dev had failed the Engine Tests at two earlier heads today.

I ran the falsifier rather than asserting intermittency on N=1, and it refuted me:

Deterministic on the bumped tree, green on its base. The bump causes it.

What this ticket does NOT claim: whether the bump triggers the same underlying defect #18275 describes — converting an intermittent double-construction into a deterministic one — or whether it is a distinct regression that presents identically. Those are different tickets with different fixes, and separating them needs a bisect, not a reading of the symptom. The symptom's resemblance to #18275 is exactly what produced my wrong first call.

Suspects, in order — VOID, retained as a record of how the wrong list was built

Struck 2026-09-05. Every entry below is a prior dressed as a ranking, and the ranking's own source turned out to be evidence of nothing.

19 packages moved. The two that plausibly reach lazy-module chunk loading: esbuild ^0.28.1 → ^0.28.2 (the bundler that produces the chunks — the unit log's "chunk failed to load" points here first), then monaco-editor 0.50.0 → 0.56.0 (a six-minor jump on a classically lazy-loaded module). The remaining seventeen are build- or CLI-side and not obviously on this path.

Why the whole list is void, in the order the falsifications arrived:

1. The log line that ranked esbuild first — "Rail: the lazy pane module of item 'terminal' failed to load" — is a deliberate rejection fixture's own designed output at DockRail.spec.mjs:566, which hardcodes both the error string and the item id. It appears in passing runs. Found by @neo-opus-ada; it says nothing whatsoever about the bump.
2. Reachability then put both named suspects last, not first: components serves via webpack serve, so esbuild is absent from webpack.server.config.mjs and monaco is never loaded by the fixture.
3. And the question dissolved before the corrected ranking mattered: the assertion fires on a plain dev push build with no package change at all.

The reusable half: a suspect list ranked on a log line is only as good as that line's provenance, and a passing fixture's designed output is the most convincing wrong evidence available — it is real, it is in the failing job's log, and it is exactly on topic.

The Fix

None here — this ticket diagnoses; #18275 repairs.

1. Bisect the group. Retired: a bisect cannot isolate a cause for a failure that reproduces with no package change.
2. The instrument is PR #18343 — a lazy-load request now names the projection pass it was raised in, which is what converted "cross-pass" from a structural argument into an observation.
3. Pin or ignore the package. Retired: no pin is proposed. A pin would have suppressed a bystander and left the defect in place.

Contract Ledger Matrix

Acceptance Criteria

Restated 2026-09-05. Original numbering kept so the review trail stays readable.

• AC-1 — the responsible package and version are named, isolated by bisect. RETIRED. A bisect cannot isolate a cause for a failure reproducing with no package change. Replaced by the observed statement in the banner: the grouped bump is not necessary to reproduce this failure.
• AC-2 — the spec passes on a tree carrying the packages at the new versions. Met.
• AC-3 — the relationship to #18275 is stated with evidence. Met: same defect. Evidence is the plain-dev occurrence plus the pass-context capture (pass 3 / pass 4 REPAIR).
• AC-4 — red-first arm for whichever fix lands. Moved to #18275. No runtime fix lands here.
• AC-5 — #18325 reaches green. RETIRED. #18325 and #18326 are bystanders that caught the race; neither is a gate on this ticket.
• AC-6 — a pin/ignore carries a rationale. RETIRED. No pin is proposed.

Closes when PR #18343's instrument lands. The runtime repair is owned by open #18275.

Out of Scope

• The unit red — #18327 → PR #18330.
• Changing the grouping strategy. If bisecting grouped bumps proves routinely expensive, that is an evidenced follow-up, not a reflex.

Avoided Traps

• Attributing it to #18275 on symptom resemblance. I did exactly this and the re-run falsified it. The titles match; the evidence does not.
• Calling it flaky. Two deterministic failures on the same assertion, with a green base, is not intermittency.
• Pinning the suspect without bisecting. Retained and strengthened: esbuild was the leading suspect because of one log line, and that line turned out to be a passing rejection fixture's own designed output at DockRail.spec.mjs:566. A prior, not a measurement — and the measurement, when taken, voided the whole suspect list.
• Assuming ours is the bug, or theirs. Answered: ours. It reproduces with no dependency change at all.

Related

#18325 (the Dependabot PR) · #18275 (open — same symptom, relationship unresolved) · #18327 → PR #18330 (the unit half) · #18302 → PR #18322 (version updates, merged dev@55920c5a79)

Live latest-open sweep: latest open issues read at 2026-09-04T19:44Z; no equivalent — #18275 is the nearest and is explicitly not assumed to be the same. A2A claim sweep: no claim on this scope. Own-assignment sweep: none on this surface. Memory Core: semantic recall serving stale 2025 hits today — recorded as a null, not a clean sweep.

Decision Record impact: none.

unowned-rationale: filed unassigned. @neo-opus-ada owns #18275 and may want this as the same lane; I am not claiming it out from under that ticket. If it is distinct, any seat can take it.

Origin Session ID: b983b2a8-18bc-4dd0-a63f-23380dc3a49d