Repository navigation
Conversation
test-devtools.ts reported that isolated runtimes do not restart after a reload (LegendApp#291). They do: the test could not see it. - The driver watched mounts through the surface presenter of the React instance it started with. A reload creates a new instance with its own presenter, so the driver saw no mount of the reloaded UI, and navigate delivered the deep link before the reloaded app listened for links. The host now re-attaches the observer to the new presenter when the main host restarts, and the driver waits for the reloaded UI to settle. - The worker's new debug target appears in /json/list shortly after the screen shows it running, so the test polls for it. The reload step now asserts the restart instead of reporting it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Targets #219 (the Kitchen Sink gate). Part of #291.
Why
scripts/test-devtools.tsprintedKNOWN ISSUE #291: the worker runtime did not restart after the reload. Isolated (worker) runtimes do restart after a reload. Two races in the test setup hid it.lastMount) also kept the value from before the reload. As a result,navigatedelivered the deep link before the reloaded app listened for links, and the DevTools screen never opened.hostDidStart:, ignoring worker hosts that forward it too),AppDelegate.mmre-attaches the observer to the new presenter and calls the newSparkTestDriverDidReload(), which resets the gate.navigate(and the other commands that wait for a settled UI) now wait for the reloaded UI./json/listthan the screen shows it running. The test now polls withuntil(...).The reload step now asserts the restart (
PASS reload: the worker re-registered as …-4) instead of reporting it.Evidence (Kitchen Sink dev build, M-series Mac, with #522 and #523 applied)
PASS(5/5 runs, including 2 with the final assertion)tests/test-driver.native.mm: new checks thatnavigateafterSparkTestDriverDidReload()waits for the next mount. Verified onmain's harness (red before, green after). On this branch the harness does not compile on my machine (CoreImage errors inSparkTestDriverCursor.mmandtests/test-driver.native.mm:159, with or without this change), so these checks are not run here.bun run typecheckpasses.DX-LOOP-01to04audit passes with fix: import global.css from App so edits hot-update instead of reloading #522 and fix(runtimes): accept hot updates in the generated worker entry #523.Not in this PR
ERR_THREADED_RUNTIME_FUNCTIONat the "runtime discovery" step (a new worker started right after the edit misses the added function), about 1 run in 7. Not investigated yet.🤖 Generated with Claude Code