E2E: the playground publish silently omits its scoped assets, disabling Run forever

[pal-tamas]

Symptom

PlaygroundExampleTests.Compiles_and_runs_user_code_live_in_the_browser fails from a fresh worktree with a 30s timeout clicking .pg-run:

locator resolved to <button disabled ... class="btn btn-primary btn-sm pg-run">Run ▸</button>
  - element is not enabled

The page boots and the Run button renders, so the 90s visibility wait passes. The button is simply disabled forever, and the click uses the default 30s timeout rather than the generous headroom the following assertions get.

Root cause

The published wwwroot had no _rask scoped-asset directory at all — zero files — so PlaygroundView.js was never served:

find samples/Rask.Example.Playground/bin/Release/net10.0-browser/publish/wwwroot/_rask -type f | wc -l
0

PlaygroundView.OnRenderedAsync awaits Rask.PlaygroundView.mountEditor, and only sets _editorReady = true afterwards. With the module missing that await never completes, so _editorReady stays false and Disabled: _busy || !_editorReady || IsActiveChapterLocked keeps Run disabled permanently.

Deleting samples/Rask.Example.Playground/{obj,bin} and republishing produces 6 files under _rask, and the test then passes in 7 seconds.

So this is the known static-web-assets/incremental-build glitch, but with a much worse failure mode than usual: the app builds, publishes, boots and renders, and only the editor is quietly missing.

Why it matters

• The E2E gate is not reproducible from a clean checkout. It passes in a warm worktree and fails in a fresh one, which is backwards — the fresh one is the honest test. A contributor's first run of the gate fails on something they didn't touch.
• It fails silently in the direction that looks like a product bug. The symptom is "the playground is broken", not "the build is incomplete", so the natural next step is to go debugging the compiler or Monaco.
• Encountered while running the gate for an unrelated PR (a new Rask.ObjectStore package that cannot reach the playground — it shares none of its project references).

Suggested fixes

1. Make the failure loud. BakeScopedAssetsTask already logs wrote N file(s); a project that has scoped assets and bakes 0 should fail the build rather than log it. There is already a FailOnEmpty path (BakeScopedAssetsTaskTests.FailOnEmpty_WhenRegistryResolvedButZeroBaked_ReturnsFalseAndLogsError) — it appears not to be engaged here.
2. Make the app fail loudly too. mountEditor is documented as never throwing (it falls back to a textarea), but a missing module isn't a mount failure — the interop await just never returns. A timeout or a guard that surfaces "editor module missing" would turn a permanent disabled button into a diagnosable error.
3. Have scripts/run-e2e-local.sh clean the playground's obj/bin before its publish, since that publish is already the one step that re-restores and takes the native relink.

Related: the repo already carries knowledge that a clean WASM obj/bin plus a serial build works around static-web-assets glitches; this is the same family.

[pal-tamas]

Correction to the root-cause analysis above — my diagnosis was wrong, and the fresh-worktree framing is a red herring.

I attributed this to the known incremental/static-web-assets glitch because rm -rf obj bin + republish fixed it. That was the right observation and the wrong conclusion.

The actual cause (identified by the session that owns the playground, fixed in #652): the E2E script's preceding solution build compiles the playground with -p:WasmBuildNative=false, and the gate then publishes it with the native relink — through the same obj/. The scoped-asset bake staged under obj/Release/net10.0-browser/rask-scoped is left over from the no-native build and never reaches the native publish.

That means:

• It is not worktree-age dependent. It reproduces on any repeat run. My clean rebuild worked because it erased the stale staging directory, not because the worktree was fresh.
• A single clean run is exactly the thing that hides it — verification needs the gate run twice back to back.

The two suggested fixes still stand and #652 takes one of them (a mount deadline that names the missing module instead of leaving the button hung forever). Leaving this issue open for the other, which is the more valuable half: BakeScopedAssetsTask's FailOnEmpty not engaging on this path. Turning "this project has scoped assets and baked zero" into a build error would convert the whole class of failure from a runtime symptom into something the build refuses to produce — and it is worth knowing whether the guard didn't fire or was never reached.

[pal-tamas]

#652's fix is incomplete — measured after it merged.

Rebased onto 2aaee7a and ran the gate: the playground test failed with the identical symptom (disabled Run button, 30s click timeout), and publish/wwwroot/_rask was empty. The fix is present and running — rm -rf samples/Rask.Example.Playground/obj/Release/net10.0-browser — and the publish still produced zero scoped assets.

Measured on the same worktree:

State before dotnet publish	Files under publish/wwwroot/_rask
obj/Release/net10.0-browser cleared, bin/Release/net10.0-browser left from the no-native slnx build	0
both obj/Release/net10.0-browser and bin/Release/net10.0-browser cleared	6

So the missing half is bin. The cause identified in #652 (one project built two ways into one output tree) is right; clearing only the intermediates is not sufficient.

Likely mechanism, held loosely — verified the fix, not the explanation: with bin still holding the no-native output, the publish's incremental build treats the compile as up to date and never re-runs the scoped-asset bake. Deleting the staged copy under obj then leaves nothing to publish rather than forcing a rebuild, which would make clearing obj alone actively worse than clearing nothing.

Worth noting for whoever verifies the follow-up: running the gate twice back to back does not catch this. Both runs clear obj and both leave the same stale bin, so both are wrong identically. The distinguishing variable is bin.

The FailOnEmpty half of this issue is now clearly the valuable one: two separate attempts have shaped the same failure into a silent empty publish, and a build that refused to produce a project with scoped assets and zero baked output would have caught both at the source instead of at a Playwright timeout.

[pal-tamas]

Correcting my own mechanism claim — it is contradicted, not merely unproven.

I wrote above that clearing obj alone leaves the compile up to date so the scoped-asset bake never re-runs. I did not observe that. I inferred it from the outcome, which is the same error as my earlier fresh-worktree theory.

The session that owns the playground tried three sequences and in all three the publish re-ran the bake (wrote 2 file(s)) and shipped the files:

1. build the playground with -p:WasmBuildNative=false → rm -rf obj/Release/net10.0-browser → publish
2. the same, but deleting the publish directory first — worth noting on its own, since dotnet publish does not clean its output, so leftovers from an earlier good publish can make a broken publish look fine
3. full dotnet build Rask.slnx -c Release -m:1 -p:WasmBuildNative=false → same rm → publish

That is direct evidence against my explanation, and direct evidence beats an inference.

What still stands is narrower: an A/B inside the gate harness. One run with obj only cleared failed with zero files under publish/wwwroot/_rask; the next run, whose only change was adding bin/Release/net10.0-browser to that rm, passed with PlaygroundExampleTests green in 7s. Both began from the script's own solution build, which repopulates bin.

So: the superset clean fixes it in at least one environment, the mechanism is unknown, and the deciding variable is not in the sequence as either of us understands it. It should be justified by cost — one recompile behind a native relink that already runs — rather than by any claim about why.

The right instrument if it recurs is /bl on the failing publish, then checking whether _RaskBakeScopedStaticWebAssets ran at all. I should have reached for that before theorising twice.

This also sharpens what the real fix is. FailOnEmpty turns out never to have been wired to anything, while its own documentation claimed it was — which is what sent me looking at it and concluding the guard had failed to fire, when there was no guard. A staged-vs-published comparison that fails the build with the cause makes this whole class self-diagnosing regardless of which clean is correct.

[pal-tamas]

Hit this from an unrelated branch (a docs-link guard — nothing near the playground), which is worth recording as an independent reproduction: it is not specific to whatever the playground session was doing, and a fresh worktree is enough to land in it.

Same symptom exactly — .pg-run disabled, 30s click timeout — and the same diagnostic:

$ find samples/Rask.Example.Playground/bin/Release/net10.0-browser/publish/wwwroot/_rask -type f | wc -l
0

The gate had already run green twice on this worktree earlier today, on two other branches. So the failing state is not "fresh worktree" either — it is reached by something that happens between runs, and once reached it is sticky.

Confirming the deciding variable from your A/B, in a third environment:

Before dotnet publish	Files under publish/wwwroot/_rask	E2E
as the gate left it	0	PlaygroundExampleTests fails at 30s
rm -rf obj/Release/net10.0-browser bin/Release/net10.0-browser	6	57/57

One dotnet publish between the two, nothing else changed. So bin being in the clean is what decides it, and the superset clean holds up outside the session that found it.

I did not chase the mechanism — agreed that /bl on the failing publish, checking whether _RaskBakeScopedStaticWebAssets ran at all, is the instrument rather than another inference.

Two things this adds to the case for the FailOnEmpty-style guard being the valuable half:

• The failure survives a passing gate. Two green runs on this machine did not stop the third from publishing zero assets, so "the gate passed recently" is not evidence the publish is sound.
• The symptom points away from the cause. A disabled Run button reads as a playground bug; nothing in the build output says an asset directory came out empty. A build that refused to publish a project with scoped assets and zero baked output would have named the cause at the point it happened, instead of at a Playwright timeout on someone else's branch.