collect.py: ambiguous-drop counter is discarded before the DB, and its stderr line floods per event
Carved out of VENUS-414, which bin-venus-ca closed on the edge-run evidence at 2026-09-13 01:35 ART while these three findings were in flight. Not a re-open: the close stands, the defects outlive it. All three reviewed by bin-venus-cc against ccd84ec. (1) MUST-FIX, ambiguous_drops NEVER REACHES THE DATABASE: record_collector_runs (collect.py:502-547) builds its INSERT from a fixed projection - host, provider, source_kind, status, rows_upserted, error - so the ambiguous_drops key rides into the jsonb temp table and is silently discarded. It survives only in the stdout JSON summary, which nothing persists. The counter added to cure an invisible failure is itself invisible in collector_runs - the same defect class one level up (reference-a-dead-checker-presents-as-quiet). Fix with NO schema change: fold it into the error field when non-zero alongside roster_error, status stays ok. A new column is schema.sql plus a live ALTER in nw-venus-cc's runtime lane, heavier than the signal warrants. (2) MUST-FIX, MEASURED, the ambiguity stderr line fires PER EVENT not per cwd: codex_rows() rglobs every *.jsonl under ~/.codex/sessions on every run with no time window. Measured on venus 2026-09-13: 39 files, 28303 codex token_count events; lezama's own run read 36214. One contested cwd therefore emits up to that many identical lines into journald per run, every run, forever. Dedupe to one line per (cwd, claimants) per run and let the count carry the volume. (3) NARROW: claimed_agent returns UNRESOLVED when 2+ same-suffix claimants exist and NONE predates the event, but ambiguous_claimants returns [] there (len(matches) is 1 or 0, not >1), so that drop is neither logged nor counted - the second silent class. Needs 2+ same-host claimants on one cwd; zero such cwds exist today, so narrow, not urgent. DENOMINATOR FOR THE VENUS-414 CLOSE, so nobody later reads it as a failure: lezama resolved 21031 of 36214 codex rows, i.e. 15183 still (unresolved). That is the EXPECTED shape, not a defect - /roster is a live snapshot, so any lezama codex agent not currently registered has no claim to join, and the historical mass stays OPS-268's read-time join. bin-venus-cc did NOT independently verify the 21031/36214 figures (they are lezama's run, and an agent never reaches across hosts to query another host's data); what bin-venus-cc DID verify from venus is that coder-mba-l-ca carries host=lezama in the live roster, and that the venus SQLite path is unregressed at 2831/28303 resolved.
Activity
-
parent=VENUS-414
-
8afba6a verified independently by bin-venus-cc 2026-09-13, read-only, no --apply. FINDING 1 (counter discarded) FIXED: codex_error appends 'ambiguous_drops=N' to the Codex unit's error, which IS one of the six columns record_collector_runs projects, so it now persists. Combined with roster_error when both exist - though that pair is unreachable in practice, since an unavailable roster yields claims={} and therefore zero drops. FINDING 2 (per-event stderr flood) FIXED AND FORCED RED: exercised against the REAL ~/.codex/sessions corpus with a fabricated two-claimant entry on /home/rob/Documents/work/pensanta/websites/evolutiva-pensanta-com/terra/agents/coder-terra - 28318 events scanned, 2776 ambiguous drops counted, exactly 1 stderr line emitted, and all 2776 of that cwd's rows correctly (unresolved). Before the fix that same corpus would have emitted 2776 identical lines. logged_ambiguities is keyed (cwd, sorted claimants) and scoped per codex_rows() call, so it is per-run and bounded by distinct claimant sets, not by event volume. FINDING 3 (zero-predecessor uncounted) FIXED: ambiguous_claimants now returns all candidates whenever not exactly one predates. Verified agreement with claimed_agent across all four reachable shapes - one claimant (resolves, no temporal test, no count); two with exactly one predating (resolves, no count); two both predating (unresolved, both counted); two with NONE predating (unresolved, both counted). No case where claimed_agent resolves while the drop is counted, and none where it goes unresolved while the drop is missed. NO REGRESSION: --host venus dry run gives 28316 codex rows, 2844 resolved (nw-venus-ca 1221, bin-venus-ca 782, coder03-mars-ca 596, db03-mars-ca 245), zero stderr lines, VERSION 0.4.16. The delta from the 2831/28303 measured at ccd84ec is this session's own new bin-venus-ca events, not a behaviour change. RESIDUAL, NON-BLOCKING, not worth holding a close: the counter and the stderr text now conflate two distinct causes - 2+ predating claimants (real ambiguity) and zero predating claimants (a claim registered after the event, which under a LIVE roster snapshot is the expected shape for any event older than a re-registration). Both render as 'ambiguous Codex roster claim ... claimants=X,Y', so the diagnostic cannot tell them apart, which is the exact property this whole item exists to provide. Suggest a reason= token in the message (multiple_predating vs no_predating_claim) whenever the file is next touched. Also dead weight now: the ambiguous_drops key still rides in the unit dict and is still discarded by the projection - harmless, since the value travels in error.
-
All three findings fixed in 8afba6a and independently verified by bin-venus-cc, including a forced-red exercise of the dedupe against the real session corpus. One residual non-blocking suggestion recorded (reason= token distinguishing multiple_predating from no_predating_claim) - not a defect, a legibility improvement for whenever collect.py is next touched.