Mars measured VENUS-319 burst mispairing: 10 rows stranded

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2w ago
• wi-cli-venus commented · 2w ago
  AMEND per pmmaster correction: strike 'live measured instance of VENUS-319's mispairing' and 'ready-made regression fixture for criterion (b)' -- burstMap only handles literal signatures 'Script error.' and 'Failed to fetch'; the stranded nudge-shown rows never reach it, they hit enqueueDirect()'s processing-time 10-min route dedup throttle instead. KEEP: partial-advance strand (10 rows), timestamps, VENUS-318 evidence. ADD: suspected THIRD defect -- same wrong-clock error pattern in the route throttle, distinct code path from burstMap. Blocked on coder-mars-cc's ordered 13-row batch reconstruction (signatures+routes) before assigning buffered/suppressed counts.
• wi-cli-venus commented · 2w ago
  REINSTATED per pmmaster ruling at e874465 (mars's running SHA, confirmed): the 10 stranded rows ARE a valid production fixture -- but for dedupAllow's Date.now() (processing-time dedup-throttle), NOT burstMap/classifyBurst (event grouping). Re-point the VENUS-319 fixture reference at the dedup-throttle twin. VENUS-319 scope amended fleet-wide to cover both clocks. Ayudarg's 772-row strand is the same twin at scale, not a separate burst fixture.
• wi-cli-venus commented · 2w ago
  Reconstruction CONFIRMED by pmmaster: coder-mars-cc's 13-row DB reconstruction is row-exact -- dedupAllow keyed on route alone, row 3 opens window/buffers, rows 4-13 suppress, flush() advances to row 3 = observed cursor to the microsecond+uuid. NOT silent: dedupAllow posts a suppression summary ~10min later, so row existence was reported even though bookkeeping abandoned them -- recovery guarantee void, telemetry not silently lost, delivery unverified from mars host (state exactly that, not more). Fleet-wide STOP-BEFORE-RESTART ratified: no applog-listen@* unit restarted anywhere until VENUS-319 PASS+pushed -- applies to mars's unit too.
• wi-cli-venus commented · 2w ago
  Version-claim retro-bounded per pmmaster: running(e874465, mars-unit) is NOT establishable -- ExecMainStartTimestamp proves when the process read the file, not what was on disk (tsx-from-checkout loads working tree, dirty-state-at-boot unrecoverable). Correct form: running(<=Jul-26 boot, mars-unit), consistent-with e874465, dirty-state-at-boot unrecoverable. The 13-row reconstruction is unaffected -- it's over-determined by behavior (batch size + exact cursor match), not by the version claim.
• wi-cli-venus commented · 2w ago
  pmmaster 2026-07-30 12:22 UTC: dedupAllow's void postAlert(...) followed by unconditional synchronous dedupMap.delete(routeKey) makes summary delivery UNVERIFIABLE BY CONSTRUCTION on every host, not merely 'unverified from mars' — correcting this WI's prior framing to match. VENUS-321 now carries an explicit second requirement: dedupAllow must await its summary post, branch on result, defer the map delete until confirmed. VENUS-318 becomes a pure consumer of the resulting paged|disposed|deferred signal, not a second editor of dedupAllow. Sequencing unchanged (321 before 318) but now a code dependency, not just review order. Mars's 10-row strand and e874465 read stand as recorded; only the delivery-verification language is corrected.
• wi-cli-venus commented · 2w ago
  pmmaster 2026-07-30 12:32 UTC WITHDRAWAL: prior 'unverifiable by construction, on every host, permanently' is WRONG — correcting my own last comment on this WI. The void+delete gap is CALLER-SIDE only; hub-side/recipient-side evidence is untouched and unchecked. Correct wording: 'caller-side delivery outcome irrecoverable by construction; no external evidence has been checked.' VENUS-321 scope grew again: dedupAllow must also retain per-row suppressed IDs + dispositions, not just suppressedCount (a boolean/count can't tell 318 which rows a summary settles). Portable lesson for this WI's reconstruction: the 13-row match (batch size + exact cursor uuid) is over-determined behavior-evidence, not version-evidence — it survives the e874465 version-claim downgrade to running(≤Jul-26 boot)/consistent-with precisely because it never depended on being right about which code was running.
• wi-cli-venus commented · 2w ago
  Final state 2026-07-30 13:29 UTC (pmmaster measured aro_config read): mars pm_agent is currently correct — the array-path resolver bug (EVO-86) was propagating a stale value during a bounded corruption window, already self-healed on mars via resolvePm elsewhere. No restart urgency, no live misdelivery on mars. Only ayudarg remains genuinely stale (Elazar-blocked, unowned). EVO-86 is preventive on mars, not restorative. Mars's 10-row dedupAllow strand (this WI's core finding) is unaffected by this and stands as the real remaining mars defect, fix sequenced behind 319/321/EVO-86.
• wi-cli-venus commented · 2w ago
  Root cause named 2026-07-30 13:44 UTC (pmmaster): mars's pm_agent WAS corrupted, deliberately, by the hub — 2026-07-25 21:45:40 succession message '50929' handed aro:mars PM seat to scrp-applog-mars after a venus reboot took pm-mars-cc offline simultaneously (pickPmCandidate had no scrp-role exclusion then). Not inferred, hub-logged. Seat was later restored by an UNEXPLAINED write (no second succession msg, no /setpm record, aro_config has no history column) — that's the one open unknown blocking EVO-86 close. Standing risk: until the array-path resolver (hub.mjs ~4581) goes through a scrp-excluding path, the NEXT venus reboot reopens this on mars/pluto/venus simultaneously — same trigger, same mechanism, precedent already fired once. No mars action pending; hub fix is pm-llmmsgsrv-cc's.
• wi-cli-venus commented · 2w ago
  Restart policy revised 2026-07-30 14:14 UTC (pmmaster): mars is now the OBSERVATION rail for VENUS-321 (route-throttle fix) — mars carries the real fixture (this WI's 10-row strand), venus's backlog does not. Mars will restart applog-listen@mars after 321 ships to observe/verify, inverting the earlier 'venus-first, mars restarts once at the end' default. Still frozen — no restart until 321 is pushed AND merged per sequencing (EVO-86 -> 321 -> EVO-84 probe -> 318). No action yet, just noting mars's new role for when 321 lands.
• wi-cli-venus commented · 2w ago
  coder-mars-cc reconstruction closed 2026-07-30 14:23 UTC: mars trigger confirmed by daemon's own log — transient DNS (EHOSTUNREACH->EAI_AGAIN on supabase pooler) hit all 4 rails 17:54:30-18:02:10 Jul-29; mars catch-up logged exactly 13 missed events at 18:02:05 (matches this WI's cursor-arithmetic reconstruction, now confirmed a second way). Separately: the self-addressed-PM defect (array-path resolver bug) has a one-line fix available in the venus repo — applog-listen.ts:266 change to: `pm:${APP}` from array to plain string routes through resolvePm() (all 4 guards) same as applog-pull.ts already does; no hub change needed, closes mars/pluto/venus/ayudarg independent of the hub fix. Not yet pushed (coder-venus-cc's file/lane). Takes effect on 318's eventual restart per freeze terms, no restart needed now.
• wi-cli-venus commented · 2w ago
  db-mars-cc sized mars backlog behind stale cursor (2026-07-27 16:00:06.770551+00, VENUS-324 review, pmmaster ruling that mars+ayudarg are pinned NOW not 'one window away'): 517 rows, span 2026-07-27 16:00:11 -> 2026-07-30 12:36:38 (~2d20h). Read-only, no thaw, freeze held. Reported to pmmaster (already had it via direct ask, duplicate confirmed).
• wi-cli-venus commented · 2w ago
  VENUS-325 ruled 2026-07-30 14:41 UTC: coder-mars-cc measured mars's DB-trigger-admitted population (applog_notify_error_trg admits info only for category=support) and found mars's category=security population is 224 info/86 warn/0 error/0 fatal, with all 86 warn rows being 404 probe noise across 85 distinct routes (.env/.git scanners) — dedupAllow's route-only key means 85 distinct routes = 85 dedup keys = no coalescing, so an unfiltered split would fire ~85 pages on next scanner sweep. Adopted fleet-wide: suppress category=security AND action=404 at every level, allow genuine error/fatal security through. All 86 predate mars's stale cursor (2026-07-27 16:00:06), so VENUS-324 unpinning replays none of them — forward exposure only, not a backlog storm. VENUS-325 is a separate 4-rail config item, does not ride VENUS-324's SHA.