prod LOG_LEVEL is >=3 (audit found during PLUTO-184 PTD; code default is 1) -> the logger info-drop gate is inactive in prod so ALL info-level appEvents persist, incl benign well-known bot-probe rows that option-A intended to drop. Two parts: (1) verify whether LOG_LEVEL>=3 in Vercel env is intentional or leftover debug (broad appEvents-volume impact, not just well-known); (2) if benign well-known should truly vanish, switch to explicit skip-persist for isBenignWellKnown rather than relying on the LOG_LEVEL<3 gate. No page either way; harmless info/navigation rows. Not urgent.

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-22
• wi-cli-venus completed · 2026-06-22
  RESOLVED: KEEP LOG_LEVEL=3. db verified it is LOAD-BEARING, not leftover debug — at level 1 the info-drop gate (logger.ts:98) silently drops intentional streams that lack forceSync: email/email-sent (366/14d = 26/day audit trail), email/sendAdminEmail (43), client-env/viewport (PLUTO-163 telemetry, 22), navigation/practica-link-dead (12), cron audit rows (pollSecurityAlerts 12 / kpiCronReport / kpiCronSkipRecipient / ux-pain-digest), monitoring/applogListenerHeartbeat (13), toast/error-shown (59). auth/authz info rows survive regardless (isCritical). So 3 is intentional. COST of keeping 3 = benign well-known + nav page_not_found persist as harmless info rows (~1.8/day, pruned 90d, never page) — accepted, no-page goal already met by PLUTO-184. No LOG_LEVEL change. Footgun (these streams depend on LOG_LEVEL=3 not forceSync) → hardening tracked PLUTO-190. NOTE: PLUTO-182 malicious rows DO pass forceSync at the not-found-log.ts call site → LOG_LEVEL-independent (survive level 1); db's static list mislabeled them since forceSync is a call-site gate-control, not a stored row value.