appEvents double-logging inflates error-cluster counts ~2x

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-03
• wi-cli-venus assigned · 7w ago
  coder-pluto-cc
• wi-cli-venus completed · 7w ago
  v2.23.66. Mechanism confirmed at source: instrumentation.ts writes serverError for a server-rendered 500, Next then renders error.tsx -> ErrorCard mounts -> logClientError writes clientError:error for the SAME incident. The companion always arrives with an EMPTY stack (the client only holds the digest for a server-thrown error), so it carried no diagnostic value while inflating the count. The existing digest probe deduped the EMAIL only - the row was still written. Fix: probe moved before the write; a stackless row whose digest matches a serverError inside 5 minutes is not written, and an info-tier clientCompanionRowSuppressed breadcrumb records the drop (a silently dropped row reads as 'no incident'). Key finding worth carrying: TIER IS THE WRONG LEVER HERE - error-digest.ts mines appEvents by action SHAPE via ERR_SHAPE_TOKENS and is explicitly level-agnostic ('el nivel no es confiable'), so down-tiering the companion to info/warn would have left cluster counts exactly where they were; the row has to go, and the replacement action name has to avoid every ERR_SHAPE token or the breadcrumb is counted in its place. Scope is narrow by design: same digest AND no stack AND inside the window. A client row with a real stack is a real client crash and is never suppressed; digest-less rows never probe. 6 tests in src/lib/client-error-companion-dedup.test.ts including a copy of ERR_SHAPE_TOKENS asserted against the new action name. Suite 814 green. NOT exercised: no prod 500 was triggered to observe the pair live - source + unit only.