fix(issue-43): reach iPad Pro with native notifications + in-terminal debug#44
fix(issue-43): reach iPad Pro with native notifications + in-terminal debug#44konard wants to merge 3 commits into
Conversation
Adding .gitkeep for PR creation (default mode). This file will be removed when the task is complete. Issue: #43
…rminal debug The v0.16.0 #39 fix replaced the dead-end iPad-Safari error toast with native VS Code notifications, but iPads kept showing the *old* toast. Two infrastructure bugs kept the fix from reaching the device: * The service worker was cache-first for the **app shell** with a CACHE_VERSION that was never bumped through #39 / #41. Every iPad that visited during v0.15.0 still pinned the old glue/boot.js. Switch the shell to network-first, keep cache-first only for the immutable assets (/vscode-web/, /cheerpx/, /disk/), and bump CACHE_VERSION with an `-app2` epoch so every device evicts the stale cache exactly once on activate. * The silent-shell advisory still said "run __rustWebBox.dump() in the browser console" — a dead end on iPadOS Safari, the exact device the terminal-silent-hang first surfaces on. Inline the diagnostics block straight into the terminal, surface the iPad-Safari silent-spawn signals (outputBytes, silentSpawns, slowFirstOutput) in dumpRuntime, add a `vm.diagnostics` bus method, and contribute a new "WebVM: Show Diagnostics in Terminal" command so the user can pull diagnostics on demand from the surface they are already looking at. Audited the whole codebase for surviving custom UI / browser-console hints — every notification now flows through VS Code's native API, and no user-facing string mentions a browser console.
konard
changed the title
Working session summaryPR #44 is finalized and ready for review: #44 What landed in this PRPrimary fix — stale service-worker cache. Secondary fix — debug surface the iPad user can reach. Diagnostics no longer point at the browser console (a dead end on iPadOS Safari). The silent-shell advisory inlines a Evidence + plan. Tests. 293/293 web tests pass — including 13 new SW tests and 8 new diagnostics-in-terminal tests. CI/CD pipeline is green. This summary was automatically extracted from the AI working session output. |
🤖 Solution Draft LogThis log file contains the complete execution trace of the AI solution draft process. 💰 Cost estimation:
📊 Context and tokens usage:Claude Opus 4.8: (2 sub-sessions)
Total: (3.9K new + 161.4K cache writes + 3.9M cache reads) input tokens, 38.3K output tokens, $3.945295 cost Claude Opus 4.7:
Total: (90 new + 193.5K cache writes + 5.7M cache reads) input tokens, 38.8K output tokens, $5.006792 cost 🤖 Models used:
📎 Log file uploaded as Gist (4392KB)Now working session is ended, feel free to review and add any feedback on the solution draft. |
✅ Ready to mergeThis pull request is now ready to be merged:
Monitored by hive-mind with --auto-restart-until-mergeable flag |
This reverts commit 72a06a4.
1 participant
Fixes #43.
Summary
The v0.16.0 #39 PR replaced the dead-end iPad-Safari error toast with native VS Code notifications, but the screenshot on issue #43 (taken on a fresh iPad Pro on 2026-06-15) shows the old toast still present — five weeks after #39 shipped. The #39 code was correct; two infrastructure bugs kept the fix from reaching the device.
Root cause 1 — stale service-worker cache (primary)
web/sw.jswas cache-first for every path, andCACHE_VERSIONwas never bumped through #39 / #41 / v0.16.0 / v0.17.0. Every iPad that visited during v0.15.0 pinned the oldglue/boot.jsforever. The fix:/vscode-web/,/cheerpx/,/disk/).CACHE_VERSIONtov3-…-app2— the-app{N}epoch forces a one-time eviction of stale caches on every device that activates the new SW.Root cause 2 — debug surface the user cannot reach (secondary)
Even after the cache is flushed, the silent-shell advisory (#37) still said “run
__rustWebBox.dump()in the browser console.” iPadOS Safari has no easy developer console, so the maintainer brief in #43 specifically demands: “all debug info should be output in VS Code terminal.”--- rust-web-box diagnostics ---block straight into the terminal — browser tells, isolation flags, vmPhase, shell-loop stats.dumpRuntime()surfaces the silent-shell signals (outputBytes,silentSpawns,slowFirstOutput) so a terminal screenshot triages the bug.vm.diagnosticsbus method returns{dump, terminalText}.web/glue/boot.js's shell-unhealthy notification points at the new command instead of the browser console.Requirements coverage (verbatim from #43)
web/glue/debug.js(formatDiagnosticsForTerminal),web/glue/webvm-server.js(advisory rewrite,vm.diagnostics),web/extensions/webvm-host/extension.js(new command + pty),web/glue/boot.js.docs/case-studies/issue-43/README.md,online-research.md, four.jsonevidence files, screenshot.dumpRuntimenow surfaces the iPad-Safari silent-spawn signals.online-research.md.Files touched
How to reproduce the original bug
https://link-foundation.github.io/rust-web-box/before the Still not working on iPad Pro #43 fix lands.After this PR, the toast is gone, errors arrive as native VS Code notifications, and WebVM: Show Diagnostics in Terminal prints the diagnostics block on demand.
Test plan
node --test web/tests/*.test.mjs→ 293 / 293 passing.web/tests/sw-cache-strategy.test.mjs— 13 tests covering the network-first/cache-first split, COOP/COEP synthesis, range-request bypass, activate-evicts-old-caches, and the-app{N}epoch.web/tests/diagnostics-in-terminal.test.mjs— 8 tests covering the terminal formatter, thevm.diagnosticsbus method, the extension command registration, and the boot.js advisory rewrite.web/tests/webvm-server.test.mjssilent-shell test updated to assert the new in-terminal block.cargo clippy --all-targets -- -D warningsclean.browser consoleuser-facing strings — zero matches outside documentation comments.