Flake: PandasExplorerLayoutAreaTest.Explorer_NoPythonNode_RendersToolbarAndDegradesGridWithoutHanging — 50s wait ends on the LiveFrame RedirectControl

[rbuergi]

Occurrence: PR #2147, run 32737891788, shard 2 (2026-08-24 14:28 UTC) — the only failing test in the run.

ObservableAssertionException: Expected the observable to emit a value matching the predicate within 50s.
Last of 3 emission(s) was: RedirectControl { …, Href = /Doc/DataMesh/PythonPandasNode/PandasExplorer/LiveFrame/Explorer }

Attribution: not the branch. Main's run on 5cad7dd3b executed all six shards ~45 min earlier and passed this test; the PR's diff (memex HTTP pipeline gates + portal-next e2e + clients.yml — no framework rendering paths) cannot reach the Doc sample's layout composition.

History: this test's wait was already reshaped once for a flake of the same form — f7b6a0532 (2026-08-21, "Pandas Explorer wait matches the COMPLETE composition, not the first Stack frame"). This occurrence shows a second live cause: the area emitted 3 frames and stopped at the LiveFrame/Explorer RedirectControl, i.e. the composition never advanced past the redirect within the 50s budget on a loaded shard. Per no-band-aids: the bound is the detector — the question is what stops the post-redirect composition from completing, not how to widen the wait.

Filed for attribution per the flake protocol; rerunning the shard on the PR.

🤖 Generated with Claude Code

[rbuergi]

Root-caused and reproduced deterministically — fix in #2280

It is not a slow render, and the second live cause suspected in the issue body is the right one; here
is its mechanism.

When the cold Roslyn compile of the Pandas NodeType outlives
NodeTypeEnrichmentHelpers.InFlightOverlayGrace (5 s — a loaded CI runner routinely does), the
LiveFrame instance activates against the compilation-in-progress overlay, which serves
NodeTypeLayoutAreas.CompileProgressView on EVERY area (#1411). When the build lands Ok, that view
emits Controls.Redirect(...) — and the same event recycles the instance hub: WithOverlaySelfHeal
posts a DisposeRequest to it so the next access re-enriches against the now-usable type.

A subscriber that merely keeps waiting is therefore attached to a hub that has gone away. The
redirect is the last thing it will ever see, and the remaining ~45 s of the budget are spent on a
dead stream — which is exactly the recorded shape (3 emissions, ending on the RedirectControl).

Reproduced deterministically by setting InFlightOverlayGrace to 1 ms locally, which forces the
overlay path CI only reaches under load:

tree	grace	outcome
main	1 ms	FAIL at 50 s — Last of 6 emission(s) was: RedirectControl … Href = /Doc/DataMesh/PythonPandasNode/PandasExplorer/LiveFrame/Explorer (this issue's text, verbatim)
#2280	1 ms	PASS in 2 s, following the redirect
#2280	5 s (shipped)	PASS in 2 s — fast path untouched

Occurrence count for the record: 3 in the last 300 runs — 2026-08-24 14:18 (32737891788),
2026-08-25 09:43 (32833495408), 2026-08-25 18:32 (32884343645).

⚠️ A production question this turned up, which #2280 deliberately does NOT touch

The overlay's redirect href is /{instancePath}/{area} — i.e. the URL the user is already on. On
the Blazor side DispatchView answers a RedirectControl with NavigationManager.NavigateTo(href),
and LayoutAreaView is keyed on the stream identity (Address, Reference), which that redirect does
not change. On top of that, Workspace._remoteStreamCache is keyed on (owner, reference, identity),
so even a remount can be handed back the same stream object.

If those compose the way they read, a user sitting on the compile-progress page when the build lands
gets a redirect that navigates nowhere, keeps the same mounted view, and keeps the orphaned
stream — i.e. a page that silently stops updating until a hard refresh. The test's 45 s of silence
after the redirect is the same stream state, just without a browser attached.

Two things make it worth a look rather than a shrug:

• AreaFrameClassifier.IsTransientFrame's own contract says a RedirectControl is "a frame that is
  not the area's content and will be REPLACED without anyone acting" — for this redirect that is
  only true if the client acts (navigates), so either the doc sentence or the behaviour is wrong;
• the established client sync stream has no recovery for an un-announced recycle. The re-arm
  added in PROD memex: every course cover serves the 'type has not finished compilation' fallback — Store/Plugin build has not settled #1814 (rejectedByRecycle → OwnerTeardownSettled → Resubscribe) fires only when the
  recycle rejected a message we sent; JsonSynchronizationStream's own comment spells out that a
  pure recycle writes nothing, so the change-feed latch never fires and "the heartbeat cannot rescue
  it either — it is fire-and-forget and deliberately does not resubscribe". A subscriber that was
  fully established and silent when the owner recycled gets no event at all.

Settling that needs a browser (does NavigateTo to the current URL remount LayoutAreaView?), which
is why #2280 stops at the test. Recording it here so it is not lost.

🤖 Generated with Claude Code