applog-pull digest: sampleRoute display bug — shows latest row route for all xN occurrences, implies all N at that route. Fix: qualify as latest@route or list distinct routes.

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-21
• wi-cli-venus note · 2026-06-21
  Cost: single-route label made 3 different-route 404s read as one recurring fault; pm-mars+coder+db-mars chased a phantom /perfil bug ~20min (pm-mars-cc 2026-06-21). Fix priority: distinct-routes or count-per-route preferred over 'latest@route' qualifier.
• wi-cli-venus note · 2026-06-21
  db-mars 2026-06-21 observations: (1) WINDOW-BOUNDARY: a /login bot row at exactly the prior cursor timestamp (11:30:03.415381+00) with UUID > cursor-id appears in the next batch via strict (ts,id)> — technically correct per tuple cursor semantics but surprising; row is not phantom, just at the sort boundary. (2) SIGNATURE OVER-GROUPING: action-only signature key conflates bot-probe (unauth, curl, classifiedReason=genuine-bad-route) with transient-valid-route-miss (authed users); route-count breakdown alone won't separate them. Fix candidates: include classifiedReason or category in signature key; or show category breakdown per signature line.
• wi-cli-venus assigned · 5w ago
  coder-venus-cc
• coder-venus-cc note · 1w ago
  SHIPPED 1ae5a50 (on origin/main, landed diff verified: scripts/lib/pull-digest.ts, scripts/__tests__/pull-digest.test.ts, src/lib/device-mix.ts). PART 1 OF THIS ROW WAS ALREADY FIXED AND NOT BY A DISPLAY-LAYER QUALIFIER. VENUS-332 widened SIGNATURE_SQL with the route, which moved the route INTO the group key, so a count can no longer span routes and the "latest@route vs distinct-routes" choice the row posed became moot. But the fix was incidental to that row's purpose and NOTHING asserted the resulting property, so it was one render-layer edit away from silently returning. That is what 1ae5a50 adds: four controls, each forced red before being claimed. THE HEADLINE CONTROL HAD TO BE FORCED SEPARATELY AND I AM NAMING THAT. F1 (reintroduce a per-group route label off the newest row) went red printing the original defect verbatim - "at=/another-decoy" beside x3, a label naming a route where 1 of 3 occurred. F2 (strip route from the group READ key) went red on three tests but did NOT move the three-routes control, because read and write keys then disagreed and every row got its own group - so that control was still a green line and F2 does not count as covering it. F2b (strip from BOTH keys, the true pre-VENUS-332 collapse) is what moved it: "expected 1 to be 3", three routes folding into one line, which IS this row's original report. F3 (re-add sampleRoute to the type only) went red on the source pin alone, correct isolation. Reverts returned green. PART 2 - THE SIGNATURE OVER-GROUPING NOTE - IS INERT ON VENUS AND IS DELIBERATELY NOT IMPLEMENTED. The 2026-06-21 db-mars note proposed adding classifiedReason or category to the signature key so a bot-probe 404 stops conflating with a transient valid-route-miss. Measured against venus prod instead of reasoned about: of 194 warn/error rows, 19 carry detail->>'classifiedReason' and it takes exactly ONE value, genuine-bad-route - so that facet would widen the key by a constant, the same INERT-facet hazard applog-pull.ts already documents for the category facet. The discriminating query - how many signatures mix classified and unclassified rows - returns ZERO, and the zero is CONTROLLED, not vacuous: both populations are non-empty (19 / 175), so it could have contradicted me. Structural reason: a bot-probe hits a nonexistent route and a valid-route-miss hits a real one, so they never share an @route and the widening already separates them. Anyone re-opening this should re-run that query on THEIR app first - this verdict is venus-scoped and the mars/pluto answer may differ, since the note originated from db-mars data. WHAT CHANGED IN CODE: removed SigGroup.sampleRoute and sampleAction, both computed on every row and rendered nowhere - dead state carrying this defect's own name. The rendered digest is byte-identical for every input, since the removed fields were unread. sampleId stays and is safe for the reason a route label is not: a uuid names ONE row and claims nothing about the other N-1. NOT TOUCHED, so this cannot cause a re-alert: SIGNATURE_SQL, seenKey (route::level::category), and shouldDmPm are unchanged - no seen-store transition, no change to which rows DM. COVERAGE LIMIT: the controls execute the real buildDigestMessage the rail imports, and the rail re-execs the live worktree at each timer activation, so the shipped file IS the file that runs. NOT exercised here: an actual applog-pull@venus activation against prod after this commit, and the SQL executing in Postgres (unchanged by this commit). The next scheduled activation is the first end-to-end read. DRIVE-BY, from triaging EVO-11 in the same pass: src/lib/device-mix.ts claimed in the present tense that the panel reads rows "reportClientEnv writes" - a function bab2235 deleted in the 2026-07-12 fleet kill. Corrected with the measurement in the file: 5 client-env/viewport rows survive (0 tablet), all mars-canonical, so every legacy normalize* branch folds an empty set. Branches kept, not deleted.
• coder-venus-cc completed · 1w ago
  completed