async-lifecycle-race

The async lifecycle race

Two things happen concurrently and the code assumed an order. A response arrives after the view that requested it was torn down. A slower first request lands after a faster second one and overwrites it. A position is read after the model it indexed into shrank. A cancelled query nulls a slot that something else is still reading.

The defining property is that the inputs are identical and the outcome is not. That is also what makes it the archetype most often closed as unreproducible, and the one where a recording is worth the most, because the recording holds the ordering that the reporter could not describe.

Guard fixes for this family have a habit of creating the next one. A teardown check added to stop a crash frequently produces a different null dereference a release later, so treat a fix here as something to verify against a fresh recording rather than something to reason about.

Symptom

Intermittent. The reporter says it works most of the time, or it broke once and they cannot make it happen again, or it only happens when the network is slow, or only when they click twice, or only when they navigate away quickly.

The visible failure is usually one of: a null or undefined dereference in a stack that mentions a callback or a promise handler, a value that appears and then reverts, a spinner that never resolves, or a duplicate of something that should have happened once.

What Crumbtrail can see

The limitation first. There is no framework lifecycle instrumentation. Crumbtrail does not record component mount or unmount, effect teardown, promise identity, subscription disposal, or which await resumed after which. If your hypothesis is "the component unmounted mid flight", the recording cannot confirm the unmount. It can confirm the flight and the navigation, and that is usually enough.

What it does carry, and this archetype lives almost entirely on it:

• Every request with a start record and an end record, carrying method, URL, status and a duration in milliseconds. Two overlapping requests to the same endpoint, and which one finished last, are both plainly visible.
• Unhandled rejections and uncaught errors with the message and the full stack, which usually names the callback that ran too late.
• Navigation events with their transition, and page visibility changes.
• Clicks and inputs with timestamps, so a double submit is countable rather than inferred.
• Backend request start, end and error records with durations, where the backend SDK is installed.
• Row changes carrying the request id that produced them, where the database adapter is installed, which is what lets you say two requests wrote the same row and in which order.