Context
#18408 excluded portal/LearnLinkRoutingNL from the e2e CI tier as an observed failure with no established cause, and named me its owner — deliberately, because I had guessed "needs generated learn content" and @neo-gpt-emmy showed the guide and learn/tree.json are both tracked. Rather than substitute a second guess, I recorded the honest weaker claim. This ticket replaces it with a measurement.
What Was Ruled Out
The arm passes locally, so the local instrument could not see it:
- In isolation — 4 passed (6.3s).
- At the same serial position, inside the full 14-file tier — passes as test 30 of 37, in 807ms. So it is not serial position, state accumulation or resource pressure.
The hosted failure artifact from run 34063075394 is what carries the answer.
What The Trace Establishes
The click is not the problem, and neither is the anchor:
- The selector resolved:
.neo-app-content-component >> a[href="#/learn/guides/uibuildingblocks/DockLayoutsAdoption"] >> nth=0. A missing anchor would have failed at the click, not at the assertion.
- Playwright logged
waiting for scheduled navigations to finish → navigations have finished.
- No console errors and no page errors in the whole trace.
And the frame snapshots settle it:
140971.2 …index.html#/learn/guides/uibuildingblocks/DockLayouts
141020.8 …index.html#/learn/guides/uibuildingblocks/DockLayoutsAdoption ← the click routed
141035.1 …index.html#/learn/guides/uibuildingblocks/DockLayoutsAdoption
146050.4 …index.html#/learn/guides/uibuildingblocks/DockLayoutsAdoption ← 5s later
The route changed. The content did not follow. For the full 5s assertion window the h1 stayed on the source guide — 12 × locator resolved to <h1 …>Dock Layouts: One Application, Many Windows</h1> — with the URL already at the destination.
The sibling control arm (the harness can click the app's own navigation) passed on the same runner, so the content component can update there; it is the route-driven update following an in-content link that does not, within 5s.
What Is NOT Established
Whether the content arrives later or never. The trace ends at the assertion timeout, so the two candidates are:
- A tight assertion. The destination guide's content load is slower on a hosted runner than the default 5s
toContainText window. Locally the same update lands in ~800ms, so a hosted runner would need to be ~6× slower — plausible but not demonstrated.
- A real content-update defect on the in-content-link path, which local timing happens to mask.
Naming one without the measurement is what produced the first wrong guess. The discriminator is a single hosted run with a generous timeout, and the PR resolving this ticket is that run: its own e2e-engine job is the instrument.
The Fix
Give the destination assertion an explicit, generous timeout and return the spec to the CI tier — removing its EXCLUSIONS entry so the pipeline exercises it.
If the hosted run goes green, candidate 1 is confirmed and the exclusion is discharged. If it goes red, that is the result, not a setback: it converts candidate 2 from a hypothesis into a demonstrated defect with a much narrower target than "fails on a hosted runner", and this ticket is amended rather than closed.
Acceptance Criteria
Out of Scope
- The other exclusion,
rendering/LivePreviewMultiWindow, which needs built bundles and is a different problem.
- Any change to the rewrite or the router. This ticket buys a measurement; it does not presume a repair.
Related
#18408 — the tier that excluded this arm and named the owner.
Origin Session ID: 95f9ff6e-1ba5-43b6-860a-208fbf7f4442
Context
#18408excludedportal/LearnLinkRoutingNLfrom the e2e CI tier as an observed failure with no established cause, and named me its owner — deliberately, because I had guessed "needs generated learn content" and @neo-gpt-emmy showed the guide andlearn/tree.jsonare both tracked. Rather than substitute a second guess, I recorded the honest weaker claim. This ticket replaces it with a measurement.What Was Ruled Out
The arm passes locally, so the local instrument could not see it:
The hosted failure artifact from run
34063075394is what carries the answer.What The Trace Establishes
The click is not the problem, and neither is the anchor:
.neo-app-content-component >> a[href="#/learn/guides/uibuildingblocks/DockLayoutsAdoption"] >> nth=0. A missing anchor would have failed at the click, not at the assertion.waiting for scheduled navigations to finish→navigations have finished.And the frame snapshots settle it:
The route changed. The content did not follow. For the full 5s assertion window the
h1stayed on the source guide —12 × locator resolved to <h1 …>Dock Layouts: One Application, Many Windows</h1>— with the URL already at the destination.The sibling control arm (
the harness can click the app's own navigation) passed on the same runner, so the content component can update there; it is the route-driven update following an in-content link that does not, within 5s.What Is NOT Established
Whether the content arrives later or never. The trace ends at the assertion timeout, so the two candidates are:
toContainTextwindow. Locally the same update lands in ~800ms, so a hosted runner would need to be ~6× slower — plausible but not demonstrated.Naming one without the measurement is what produced the first wrong guess. The discriminator is a single hosted run with a generous timeout, and the PR resolving this ticket is that run: its own
e2e-enginejob is the instrument.The Fix
Give the destination assertion an explicit, generous timeout and return the spec to the CI tier — removing its
EXCLUSIONSentry so the pipeline exercises it.If the hosted run goes green, candidate 1 is confirmed and the exclusion is discharged. If it goes red, that is the result, not a setback: it converts candidate 2 from a hypothesis into a demonstrated defect with a much narrower target than "fails on a hosted runner", and this ticket is amended rather than closed.
Acceptance Criteria
portal/LearnLinkRoutingNLis out ofEXCLUSIONSand insideRUN_PATHS, and the selection floor still passes.e2e-enginerun executes the arm, and its result is recorded on the PR whichever way it goes.rewriteLinksinvocation, not by inspection.Out of Scope
rendering/LivePreviewMultiWindow, which needs built bundles and is a different problem.Related
#18408— the tier that excluded this arm and named the owner.Origin Session ID: 95f9ff6e-1ba5-43b6-860a-208fbf7f4442