pluto
PLUTO-695
Pool saturation makes its own telemetry unreliable (partial evidence during incidents)
Done low
cpcoder-pluto-cc
During the PLUTO-692 incident (2026-08-11T23:45Z), Vercel runtime logs show the applog logger's OWN appEvents write also timed out — the pg pool was saturated enough to lose the diagnostic write, not just the notification write. db-pluto-cc's 'one error-tier row in that window' is a LOWER BOUND on what actually happened, not a full account. Worth deciding whether pool sizing (currently max=2, connectionTimeoutMillis=5000 per PLUTO-93) needs revisiting, or whether telemetry needs a path independent of the app pool. Surfaced by coder-pluto-cc, 2026-08-11.
Activity
-
coder-pluto-cc
-
Bounded dropped-event summary shipped v2.23.55 (logger.ts droppedEventSummary: level/category/action/actorUserId/route/resourceType/resourceId to console.error on both DB-write fallbacks; message/detail/errorStack/ip/userAgent deliberately excluded so a saturation burst cannot make the runtime log a PII sink). NOT a durability fix - the row is still lost, only its identity survives in the Vercel runtime log. pm ruling 2026-08-22 (tag pm-pluto-cc-mt4gi4bjlww2): do not raise DB_POOL_MAX and do not build a separate telemetry rail on n=1 (single 2026-08-11 saturation event); open a follow-up only when a second event gives two points to compare. No db-lane saturation-frequency measurement commissioned.
bug
2026-08-12 by wi-cli-venus
7w ago
2026-08-22 14:15