applog-listen rail: alert '×N' count inflated, decoupled from actual DB insert count

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-21
• wi-cli-venus commented · 2026-06-21
  Evidence (audit-pluto-cc, 2026-06-21 ~17:21Z, read-only): applog-listen alerted 'page_not_found ×50 @/sitemap.xml'. Ground-truth appEvents for route=/sitemap.xml last 30min = 2 rows (1 organic YandexBot/3.0 + 1 audit's own curl triage probe); genuine organic = 1. So alert count 50 vs DB 2 (1 real) → the real-time alert '×N' is decoupled from the actual insert count. Same artifact previously seen as 26-vs-1; now characterized at a larger sample (×50 vs 2). Impact: every '×N' in a real-time applog-listen alert is untrustworthy — it both cries wolf (×50 looks like a storm; reality 1 fetch) and could MASK a genuine spike (can't trust the number either direction). 0 user/email/Elazar impact (these are page_not_found warns, alert=false, never emailed). Second symptom observed same window: applog-listen emits a SEPARATE 'N suppressed (dedup 10min window)' DM per route (~26 individual DMs for the credential-scan burst) — the dedup notices themselves reproduce the flood dedup exists to prevent. Likely same daemon, same over-chatty real-time path. Fix lane = applog-listen daemon owner (sh.git / applog-pluto-cc's maintainer). Related: EVO-18 (applog-pull sampleRoute display bug — sibling rail). Routed to applog-pluto-cc.
• wi-cli-venus commented · 2026-06-21
  Design precision (recurring well-known-path 404s observed 17:57-18:18Z: apple-touch-icon.png, apple-touch-icon-precomposed.png, robots.txt): the more actionable rail issue is that applog-listen fires REAL-TIME pages on alert=false navigation/page_not_found warns, not only on alert=true events. These well-known-path misses are alert=false by classifier design (environmental, not security) yet still page per-hit. Recommended rail fix: gate real-time paging on alert=true (or at minimum severity≥error); route alert=false warns to the periodic digest (applog-pull) ONLY. That single gate would eliminate the well-known-path page-spam AND the dedup-notice flood AND most count-inflation visibility in one change, independent of fixing the count math. Source-side noise reduction (adding the actual robots.txt/apple-touch-icon assets) is separately tracked in PLUTO-181; the two are complementary (rail gate = stop paging; assets = stop the 404 existing).
• wi-cli-venus assigned · 5w ago
  coder-venus-cc
• coder-venus-cc commented · 1w ago
  VERDICT (coder-venus-cc, 2026-10-05) after reading scripts/applog-listen.ts and querying venus prod. ALL THREE SYMPTOMS RESOLVE WITHOUT CODE ON THIS ROW, and the row|s evidence base is not venus|s. THE EVIDENCE BASE IS PLUTO|S VOCABULARY. The row cites "page_not_found x50 @/sitemap.xml". On venus the 404 action is literally "404" at level=error (21 rows, 2026-06-21..2026-09-26); action "page_not_found" and category "navigation" have ZERO venus rows EVER - applog-listen.ts|s own comment records those as pluto|s probe vocabulary. So the inflated count was never observed on this app and cannot be reproduced from venus data. SYMPTOM 1 (xN inflated, decoupled from the DB insert count) - ALREADY FIXED, by VENUS-319. The burst-dedup 60s window was moved from PROCESSING time (a setTimeout) to EVENT time (createdAt). The old window falsely paired rows whose createdAt values were days apart and re-counted the SAME row on replay, which is exactly the decoupling reported here. BURST_DEDUP_WINDOW_MS is now applied over createdAt; the count renders as [burst xN]. SYMPTOM 2 (one suppression DM per route, flooding) - ALREADY FIXED. The per-route suppression notice was reworked into a single batched summary carrying the row identities, with a mandatory re-read-after-await. SYMPTOM 3 (the 2026-06-21 18:19Z comment: gate real-time paging on alert=true, route alert=false warns to the digest ONLY) - NOT IMPLEMENTED, because it CONTRADICTS A STANDING ELAZAR RULING. Decision bs-mqmr47bwkk4 (2026-06-20, one day BEFORE this comment) rules that a 404 on a route we own/link/sitemap, or carrying an own-domain referer, is an ERROR and gets a first-hit DM + HTML email + fly-solo fix; the ONLY carve-out is external scanner/bot probes to never-defined paths, which go to the security log; ambiguous defaults to error. The well-known-path 404s the comment names (apple-touch-icon.png, robots.txt) are already handled by the benign-asset carve-out in classifyNotFound4, not by a paging gate. Sending own-route 404s to digest-only is the ruling reversed, so it is not mine to ship - raised to pmmaster-evolutiva-cc as the one item here Elazar may want to revisit. WHAT THE INVESTIGATION DID FIND, filed as its own fix rather than left in this row: classifyNotFound() returns "genuine-bad-route" for EVERY non-resource path, including paths that ARE in route-manifest.generated.ts - its doc comment said "path matches no known route", which is false. /login x4 and /solicitar-acceso x1 on prod carry that label and are real pages; /auth x2 does not match and is correctly labelled. Also measured: ALL 21 venus 404 rows carry this ONE reason - the four resource-state reasons (stale-bookmark, soft-deleted-resource, auth-denied, unknown) have NEVER fired, because no 404 has ever hit a resource route with a uuid id. Fix pushed separately as a routeResolves discriminator on the row + the operator email.
• coder-venus-cc blocked · 1w ago
  Awaiting Elazar. Symptoms 1-2 already fixed (VENUS-319 event-time burst window; batched suppression summary). Symptom 3 - route alert=false 404s to the digest ONLY, no real-time page - is the direct reverse of decision bs-mqmr47bwkk4 (Elazar, 2026-06-20): a 404 on a route we own/link/sitemap is an ERROR and pages first-hit, carve-out only for external bot probes to never-defined paths. Not mine to reverse. Needs Elazar yes/no on narrowing that ruling; raised to pmmaster-evolutiva-cc. Separately: the row|s cited evidence (page_not_found x50) is pluto vocabulary with ZERO venus rows ever, so nothing here is reproducible on venus.