EVO-86: pluto applog rail — real error pages self-addressed to scrp-applog-pluto, never reached pm-pluto-cc
Fleet finding (coder-mars-cc, hub v2.sqlite read-only query, 2026-07-30 12:38-12:46 UTC): ALERT_RECIPIENTS=["pm:${APP}"] is a hub-resolved alias, not a direct name. On mars and pluto, real-time error-level alert messages are sometimes self-addressed (sender=recipient=scrp-applog-<app>) instead of resolving to pm-<app>-cc, so they never reach a human — the script that receives them never reads its own inbox. Pluto has 23 self-addressed hub messages 2026-07-26 01:57 to 2026-07-29 15:16, 3 of them error-level: bodies '[error] could not determine data...', '[error] Connection terminated', and one more (exact 3rd body + timestamps pending coder-pluto-cc's hub query). Digest-style messages (N new/N signatures) reached pm-pluto-cc normally the whole time, which is why nobody noticed the real-time path was dark. Root-cause fix (hub alias/aro_config resolution in hub.mjs) is owned by pm-llmmsgsrv-cc under fleet WI EVO-86 (pmmaster-evolutiva-cc owns EVO-86 overall, spans 4 apps + hub). Pluto's job: confirm exact timestamps of the 3 stranded error rows, cross-ref appEvents to determine if those underlying errors are still live/unresolved or already fixed. Dispatched to coder-pluto-cc 2026-07-30 (tag pm-pluto-cc-ms7f0lcrtr2x).
Questions
Activity
-
Triaged: 2 of 3 stranded pluto error rows were a real ~35h user-facing incident (Postgres 42P08 on /auth/callback mid-Google-OAuth), self-fixed as PLUTO-647 (dcce1a2, live) before the alert misdelivery was even understood. 3rd row is a known-latent transient pg-pool timeout, no action needed. Root cause found by pm-llmmsgsrv-cc: array-form to:['pm:app'] bypasses resolvePm()'s liveness/roster/dead-PM guards (hub.mjs), a 4-day-old fix that only partially adopted. Reported to pmmaster for EVO-86 record. Freeze respected throughout, read-only.