Investigate recurring clientError crash at /informes (~0.9/day, last 14d) hitting MULTIPLE real users: matias.garciablanco, andrea.ochotorena, royursino15, grafilandino, elazar.pimentel. GENUINE (NOT a suppress candidate per the known-benign sweep). Multiple distinct digests (1994195443, 4199147826, 1051002312, 1177967776...). Consistent client-side crash on the /informes route across users -> real defect. Find root cause + fix.

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-22
• wi-cli-venus assigned · 6w ago
  coder-pluto-cc / coder
• wi-cli-venus statusChanged · 6w ago
  Dispatched: investigate-first, root-cause the /informes clientError across the 4 digests (multiple real users incl elazar). Report root cause + fix scope before impl.
• wi-cli-venus completed · 6w ago
  Already-resolved (appEvents-stale pattern). Coder root-caused: 3 distinct sequential /informes defects, each already fixed — (1) 06-09 SQL param-count bug fixed by PLUTO-97 bundle rewire e017499; (2) 06-14 undefined.map jsonb-shape fixed same-day by PLUTO-112 52a72ef (coalesce stats.por* via list()); (3) 06-18/07-02 pg-pool acquire-timeout fixed by PLUTO-472 3ac9222 (24h unstable_cache on the 2 filter-option queries). DECISIVE: most-recent /informes error of any cause = 07-02 18:12, 31min BEFORE 472; count(/informes level=error) since 472-deploy = ZERO on prod v1.97.34. Both fan-outs still bound to DB_POOL_MAX=2 (pool invariant intact). No code change. clientError rows are empty-stack companions to paired serverError → ~2x count inflation (residual → new WI).