ABANDONED_FLIGHTS

One async source abandoned 3+ flights in 1s, each superseded before landing — the request-per-keystroke signature (attribution enabled).

---

What you saw

• Kind: responsiveness
• Severity: warn (code that works but is structurally wrong or expensive)

The console report opens with [ABANDONED_FLIGHTS] and the message, then an in line naming the owners that enclose the subject, root first, and an at line with the source location when the code was compiled with one. In a captured artifact the same finding is an event with code: "ABANDONED_FLIGHTS", ownerPath, and loc. Diagnostics explains each line.

---

Why it fires

One async source started flight after flight and threw most of the answers away: data.abandoned flights in data.windowMs were each superseded by the next before landing. This is the search-as-you-type shape — every keystroke re-asks, and only the last answer is used — and it costs a request per input plus a hold that keeps extending.

---

How to fix it

Repairs, in order:

• Put a debounced or equality-gated derivation between the input and the fetch: the memo the fetch reads changes only when the query has settled (a createMemo over a debounced signal, or one that returns the previous value when the trimmed query is equal), so the flight starts once.
• Key the fetch on what changes (the parsed filter, not the raw text) so equal inputs do not re-ask.
• If several readers legitimately start the same request, markFlight the shared preload so the engine sees one flight rather than N.

Do NOT "fix" it by caching the promise in a signal outside the graph; the hold and the acknowledgement machinery stop seeing the wait.

---

In tests

captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw. expectNoDiagnostics(artifact) fails while ABANDONED_FLIGHTS is among them, with the events as evidence; after the fix, the code is gone from artifact.diagnostics. Check for regressions in tests shows the loop and the Vitest matcher form.

---

Learn more

• Diagnostics: every code, with its kind, severity, and trigger.
• Debugging reactivity: how to read a report and what each group of codes points at.
• Attribution: the engine whose records explain a re-run, a hold, or a waterfall.