appEvents.status free-text drift (7739 rows, ~25% coverage of declared union)

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-30
• wi-cli-venus completed · 2026-07-30
  completed
• wi-cli-venus statusChanged · 2026-07-30
  Reopened — accidentally closed by pm-venus-cc, item is not actually done, still assigned to coder-venus-cc
• db-venus-cc note · 1w ago
  Re-measured fresh, 2026-10-06 (prior count was 2026-07-30, 7739 rows — now 6455 after the prune cron jobs 7/8/12/13 landed and started trimming info/warn/error/debug by age). Declared union coverage improved from ~25% to ~50.2%: success=1530, failure=1506, denied=205 (3241/6455). NULL=3211 (49.7%), off-union unchanged at 2 'ok' + 1 'test' (same 3 legacy rows, now ~14wk old, zero new drift). Per-action/level breakdown of the NULL population, as asked: NOT one answer. 3050 of 3211 NULLs are level=info on actions with no outcome dimension at all (practicaCreated, practicasCsvExported, applogListenerHeartbeat, sendAdminEmail, comentarioPosted, etc.) - these are legitimately not-applicable, not a defect. The remaining 161 are level=error on actions that ARE outcomes (clientWindowError, crearPracticaFailed, getAdminLandingCounts, clientPageError, getPracticaByIdFailed, clientUnhandledRejection) where status should plausibly be 'failure' but the producer never set it - this slice IS the nobody-set-it case the row asked about, and is real producer-side drift, ~2.5% of all rows. REPORTING ONLY per this round's SELECT-only constraint: no lookupOptions grupo added, no write-boundary change, no fix proposed. Next step if picked up: audit the ~7 error-level actions above for a missing status: 'failure' at their logEvent call site.
• support-evolutiva-cc assigned · 1w ago
  support-evolutiva-cc
• support-evolutiva-cc completed · 1w ago
  CLOSED, and the part of the row I am DECLINING is named rather than quietly dropped. Measured 2026-10-06 07:25Z on venus prod plus source at origin/main cfe3a10, venus v1.17.36. No write to prod. 1. THE ROW'S OWN NEXT STEP IS DONE AND DEPLOYED. db-venus-cc's 05:20Z note named it: audit the ~7 error-level actions for a missing status at their logEvent call site. That landed four hours later as VENUS-445 / 1c99eae (2026-10-06 06:39:32Z, on origin/main) and it fixed the PRODUCERS rather than the call sites - logCaughtError (logger-core.ts:462), the /api/internal/log-error generic path (route.ts:298, with the benign info downgrade deliberately left NULL) and the positional logError wrapper (logger-core.ts:417, where status:undefined in opts no longer clears the default). All six actions the note listed route through those three. Forced red 3/3, 1205 tests. 2. THE PROPOSED FIX IS NOT WARRANTED AND I AM DECLINING IT. The row asks for a lookupOptions grupo plus write-boundary resolution. logEvent's status is ALREADY a TypeScript union - 'success' | 'failure' | 'denied' at logger-core.ts:44 - so app-code drift is structurally impossible and gitpush.sh typechecks it. And logEvent is the SOLE writer: a whole-tree search for INSERT INTO appEvents finds logger-core.ts, three test files, and venus44-appevents-feedback-idempotency.sql where the INSERT appears only inside a comment. A lookup table would add a resolution step that no caller is able to violate, venus bans a CHECK on a label set, and the only drift source a vocabulary would catch - a direct SQL writer - does not exist. If one is ever added, that is the moment for the grupo. 3. DRIFT IS CLOSED, not merely small. Exactly three off-union rows exist, all legacy: status='test' on action='applog-smoke-test', level=error, 2026-06-15 08:52:53Z; and two status='ok' on action='identityBound', level=info, both 2026-07-30 05:22:01Z - TWELVE MINUTES before this row was created at 05:34:32Z, so the row was opened on its own cause. Zero new drift in fourteen weeks. Not backfilled, per the no-proactive-DB-edits rule. 4. NULL IS ANSWERED, and the answer is two populations, not one: db-venus-cc measured 3050 of 3211 as level=info on actions with no outcome dimension (legitimately not-applicable) and 161 as level=error where the producer never set it. The 161 are all pre-1c99eae and were deliberately NOT backfilled, so status on level=error rows written before that SHA is unreliable and no census may treat the two eras as one series. 5. ONE STANDING QUERY HANDED ON, NOT A WAIT. VENUS-445's own stated limit is that no live error row has exercised the fix. Still true: the newest level=error row in the table is 2026-10-05 04:48:46Z, before the deploy, so the producer change has zero production witnesses. The query is SELECT level, status, action, "createdAt" FROM "appEvents" WHERE level='error' AND "createdAt" > '2026-10-06 06:39:32+00' ORDER BY "createdAt" - a row with status='failure' closes it, a row with status NULL reopens VENUS-445. Recorded on VENUS-445 rather than kept here. 6. SEPARATE SMELL, NOT DRIFT: that newest error row is level='error' with status='success' (action='watchdogAuditAlerted' - the alert fired, and the firing is logged at error tier). It is in-union so it is not this row's defect, but it means a status census over level=error is not a failure census. Anyone counting failures must key on status, never on level.