Repository navigation
aggregator(snapshot-records): recordsFromProviderUsage never range-checks used_percent — a Codex window at -20% or 1e9% is appended as measured pct history against its own limit:100 #2568
Description
Problem
recordsFromProviderUsage (pm-stack/aggregator/src/snapshot-records.ts:236-279) derives Codex quota snapshot records from the keeper's provider-usage snapshot JSON, but the window check is only typeof win.used_percent === "number" (snapshot-records.ts:261). Any finite number — negative, over 100, or absurd — becomes a pct record stamped with limit: 100:
used_percent: -20→ record{serviceId: "openai:codex", metricId: "7-day", value: -20, unit: "pct", limit: 100, source: "api"}used_percent: 150→ value 150 against its own stated limit of 100used_percent: 1e9→ value 1000000000
Evidence (verified this run, main 86b7d01)
Laptop Bun probe importing the real snapshot-records.ts + snapshots.ts (md5-matched to this repo's main; probe at laptop ~/git/fleet/probe-2026-10-29-laneB-codexpct/):
used_percent=-20→ 7-day record value -20,isSnapshotRecord(record) === trueused_percent=150→ value 150, passes the store gateused_percent=1e9→ value 1000000000, passes the store gateused_percent=42(control) → value 42, passes
The append path offers no second line of defence: scripts/append-usage-snapshots.ts (--from-provider-usage mode) filters derived records through isSnapshotRecord (src/snapshots.ts:295-310), which checks only that a numeric value is finite — no pct range check (the limit/resetsAt side of that gap is #2483). The records then enter the append-only snapshot store via the outbox/collector, and monthly compaction (snapshots.ts rollups) preserves each series' min/max indefinitely — a single glitched keeper read (the Codex usage endpoint is an external API whose values this code does not control) permanently poisons the openai:codex history series and every chart/pace consumer that assumes a pct value sits within its own record's limit (cf. #2346, where validator-passing pct records throw in projectPace).
The sibling writers in the same file validate their domains (window seconds must match a known window exactly or the window is skipped); only the percent value itself is unchecked. Note the contrast inside the same function: a window with an unrecognised limit_window_seconds is dropped silently rather than recorded under a guessed metric — the percent deserves the same fail-closed treatment.
Why it matters
Snapshot history is append-only and treated as measured fact (source: "api"). A negative or 1e9-percent record is not a display glitch that ages out: compaction keeps it as the series extremum forever, and it misstates Codex usage in the quota history the stewardship cycle reads.
Acceptance criteria
recordsFromProviderUsageemits a Codex window record only whenused_percentis a finite number in [0, 100]; out-of-range windows are skipped (the rest of the snapshot's records are still derived).test/snapshot-writers.test.tsgains cases: negative, >100, and non-finite-shaped used_percent values produce no Codex record for that window, while the other window and the sessions record are unaffected.- Existing snapshot-writers tests stay green (the 12% / 3% happy path at test lines ~184-185 unchanged).
Dedup
Checked this run against open + recently closed issues: #2553 is the Turso writer's negative counts (different writer/function), #2264 is snapshot-records' shape-only dates (different field), #2483 is the store gate's limit/resetsAt checks, #2346 is the downstream projectPace throw. No existing issue covers recordsFromProviderUsage's percent range.
Activity
dezren39 commentedon Oct 30, 2026
🤖 Agent note · filed
3 remaining items
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done
199d9f2e222c17826533dc3d9320aebd88aab533; the out-of-range positive-window defect is reproduced and the stale negative-store claim was corrected.bun test test/snapshot-writers.test.tspassed (17 tests, 56 assertions); current out-of-range behavior documented on the issue.dezren39 commentedon Nov 3, 2026
🤖 Agent note · triaged — already done, closing with evidence
Evidence the acceptance criteria are met at current main:
pm-stack/aggregator/src/snapshot-records.ts:300-303—recordsFromProviderUsagenow skips a window unlessused_percentis a finite number in [0, 100] (typeof+Number.isFinite+< 0/> 100checks), exactly the fail-closed skip the issue asked for; other windows and the sessions record are unaffected.pm-stack/aggregator/test/snapshot-writers.test.ts: negative (-1, line ~223), >100 (100.01, line ~242) and non-finite (Infinity, line ~243) windows produce no Codex record; boundary 0 and 100 (lines ~260-261) and the original 12% / 3% happy path (lines ~200-201) still emit.Closing #2568 as completed — the work it asked for is landed and tested on main.
developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/low). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03