fix-errors

A methodology for fixing unhandled errors surfaced by the VS Code error telemetry dashboard, where each issue typically arrives with an error message, a stack trace, a hit count, and an affected-user count. The central principle is that the fix almost never belongs at the crash site: adding a typeof guard, swallowing the error in a try/catch, or returning a fallback value only masks the problem while the invalid data continues to flow through the system and fails elsewhere.

The recommended approach is to trace the data flow upward through the call stack, reading each frame from bottom to top to understand what data is passed, what is expected, and where it originated (IPC message, extension API call, storage, user input), in order to locate the producer of the invalid data rather than the consumer that crashes on it. When the producer cannot be identified from the stack alone — for example when only the receiving IPC handler is visible and the sender lives in another process — the guidance is to enrich the error message with diagnostic context (the type and a truncated representation of the invalid value, plus the operation or command that received it) without silently swallowing it, so the error remains visible in telemetry and reveals the sender on the next cycle. When the producer is identifiable, the fix goes there: validate or sanitize data before sending it over IPC, storing it, or passing it to APIs, and ensure serialization preserves types (for example URIs serialized as UriComponents objects, not strings).

A recurring instruction is to find and read the code that constructs the error before proposing any fix, since the construction code reveals trigger conditions, subtypes, and whether the error is even actionable — illustrated with a ListenerLeakError example whose 'dominated' versus 'popular' classification dictates entirely different strategies. Additional guidelines include truncating user-controlled values to avoid PII, not changing shared utilities like URI.revive in ways that affect all callers, running relevant unit tests, and checking for compilation errors via the build task before declaring the work complete.