The archived March 17 incident story begins with a shed configurator that blinked, crashed, or froze during style changes. It describes a long sequence of attempted fixes and a second problem: uncertainty about which checkout supplied the running application.
The report is a historical narrative. This edition has not rerun the incident or independently verified its claimed fix count, duration, or final production state.
Identify the running version first
Before changing code, establish which process serves the page, which directory it uses, and which revision is loaded in the browser.
A correct patch in an inactive checkout cannot change the observed failure. Several workers can spend hours comparing results from different versions without realizing it.
Record the reproduction against an identified version. Keep that identity attached to screenshots and logs.
Trace resource lifetime
The draft attributed the graphics failure to resources being disposed while the scene could still reference them. It proposed pausing rendering, waiting for submitted GPU work, disposing the old scene, rebuilding, and resuming.
That is an architectural idea to inspect in context, not a universal disposal recipe. Completion of already submitted work does not ensure that later work will not reference the same resource.
Remove or replace future references and coordinate the application’s update path. Consider shared textures, asynchronous loads, and operations that may complete after the style change.
Test the transition repeatedly
The steady-state scene may render correctly while transitions fail. Exercise rapid style changes, slow asset loads, resizing, navigation away, and return.
Watch for old callbacks reattaching obsolete content. Check whether repeated transitions increase retained memory or leave an animation loop running twice.
Measure and inspect the actual behavior. A delay that makes a race rarer is not the same as a lifecycle rule that prevents it.
Distinguish queue completion from safe retirement
The current GPUQueue documentation defines onSubmittedWorkDone as waiting for work submitted by the time it is called. It does not stop later submissions. Adding an await without changing ownership can therefore leave the original race intact.
For a new investigation, record a scene generation on every asynchronous load and render submission. When replacing a scene, stop future references to its owned resources, reject stale completions, and release resources only through the owner that understands any sharing. Use queue completion where the rendering API and actual resource lifetime require it; do not insert a global wait after every frame.
This is a diagnostic method, not a reconstruction of what happened in the March incident.
Reproduce loss and replacement separately
GPUDevice.lost exposes device loss asynchronously. Recovery needs new resources for the replacement device; old device resources cannot simply be carried across.
Keep two fixtures. One repeatedly replaces scene content while the device stays valid. The other exercises device-loss handling in an isolated test and verifies either successful reconstruction or a useful fallback. Passing the first does not establish the second.
Attach a timestamped transition log containing configuration revision, active scene generation, pending loaders, and resource ownership counts. During rapid changes, confirm that a late completion is discarded rather than attached to a retired scene. Inspect the resulting image and control response as well as the counters.
The resulting evidence can support a specific lifecycle correction. It still cannot retroactively verify the archive’s claimed repair count, duration, or production outcome.
Keep fixes small enough to assess
A long incident invites unrelated cleanup and increasingly broad experiments. Preserve a clear hypothesis for each change and the observation that would support or reject it.
When a candidate fix works, identify which part changed the outcome. Remove abandoned work carefully and retain the evidence needed to reproduce the successful path.
End with the uncertainty stated
The original post claimed the central bug was solved while acknowledging many other open issues. That boundary belongs in the account.
An incident report should distinguish a local reproduction that now passes from a deployed version observed under real use. It should also identify the follow-up that would reveal recurrence.
The lasting lesson is simple: know what is running, make resource ownership explicit, and attach the claimed repair to evidence from that exact system.
Keep a good idea close.
Follow Signal Tower
