Render/server errors in appEvents (appLog): verify capture parity across pluto, mars, venus + fill gaps

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-19
• wi-cli-venus commented · 2026-06-19
  Origin: Elazar 2026-06-19. Pluto's appEvents DOES capture render/action errors (the soporte-evolutiva error emails are generated FROM appEvents rows; pg-pool storm errors were all present). Task: verify Mars + Venus capture render/server/action errors into appEvents the SAME way (level=error, category, action + the error-email pipeline), and fill any gaps so all 3 apps have parity. NOTE: separate but related — the venus real-time alert RELAY (applog-listen@<app>) was just fixed 2026-06-19 (was dialing dead direct :5432; repointed to session pooler aws-1-sa-east-1.pooler.supabase.com:5432). That fixed DELIVERY of alerts; THIS WI is about whether the errors are CAPTURED into appEvents in the first place across all 3 apps. Ref mem:pluto-applog-alert-pipeline, mem:pluto-venus-direct-port-dead-6543-workaround.
• wi-cli-venus assigned · 5w ago
  coder-pluto-cc
• coder-pluto-cc completed · 1w ago
  Verified parity: pluto src/instrumentation.ts onRequestError has the same two-leg pattern as mars (MARS-452/689) and venus (F3) - persist to appEvents (independent try/catch, never blocks the alert) + DB-independent alert email, both present and mature on all three (PLUTO-54/166/688 citations). Checked the one structural asymmetry: mars gates an edge-runtime branch (NEXT_RUNTIME!=='nodejs') because its pg/nodemailer imports break on Edge. Pluto has zero edge-runtime surface - every API route explicitly declares runtime='nodejs', no middleware/edge equivalent - so that branch doesn't apply here, not a gap. No capture-parity gap found on pluto's side. Ticket had zero notes since filing 2026-06-19; each app had independently matured its own leg since.