Repository navigation
aggregator(snapshot-records): recordsFromDeepseekBalance takes the ¥ line's first date-shaped string unchecked — an impossible date (2026-02-30) shadows the section's valid Last-checked date, the record fails isSnapshotRecord and is silently dropped as 'already present' #3379
Description
Problem
recordsFromDeepseekBalance (pm-stack/aggregator/src/snapshot-records.ts:173-190, the DeepSeek PAYG CNY balance derivation from #1052) takes its observation date from the ¥ line with a bare date-shaped regex and never checks it is a real calendar date:
const date = /\d{4}-\d{2}-\d{2}/.exec(line)?.[0] ?? lastCheckedDate(section) ?? freshestDate(section); // :182Both fallbacks it shadows are #2264-hardened: freshestDate (same file, :45) filters candidates through parseIsoDate precisely so "an impossible date like 2026-02-30 or 2026-13-01 in prose must not win", and recordsFromPools (:206) uses only those validated fallbacks. The DeepSeek path is the one derivation in the file that bypasses the discipline — and because the regex matches an impossible date, the ?? chain never falls through to the section's valid Last checked: date.
Verified (laptop probe, real files at main e6577a9, snapshot-records.ts sha256 dc4d2b62…)
Probe: ~/git/fleet/probe-2026-11-01-laneA-deepseekdate/ (imports the real recordsFromDeepseekBalance / freshestDate / lastCheckedDate and the real isSnapshotRecord gate):
- Control — ¥ line
(2026-10-25 read): recordts=2026-10-25T12:00:00Z,isSnapshotRecord=true. - ¥ line
(2026-02-30 read), section Last checked: 2026-10-30: recordts=2026-02-30T12:00:00Z,isSnapshotRecord=false. - ¥ line
(2026-13-01 read): recordts=2026-13-01T12:00:00Z,isSnapshotRecord=false. - Control — no date on the ¥ line: falls back correctly to
ts=2026-10-30T12:00:00Z(Last checked), gate passes.
Why it matters
The poisoned record is not stored — it is silently lost: SnapshotStore.appendLocked drops gate-failing records with records.filter(isSnapshotRecord) (snapshots.ts:610, no warning), and the backfill's summary counts everything not appended as "already present" (scripts/backfill-usage-snapshots.ts:434), so a mistyped/impossible date in the quota-view prose (e.g. 2026-02-30 for a Feb 28 read, or a month/day transposition) makes the DeepSeek reserve's balance observation vanish while the run reports it as a dedupe. The correct read date was sitting in the same section's Last checked: bullet the whole time. This is exactly the failure #2264 fixed for freshestDate; this one call site was missed.
Fix sketch
Validate the on-line candidate the same way the rest of the file does — e.g. take the first real date on the line (parseIsoDate(d) !== null, mirroring freshestDate), and only then fall back to lastCheckedDate(section) ?? freshestDate(section). An impossible on-line date should behave like no on-line date, not like a successful match.
Acceptance criteria
- A ¥ line carrying an impossible date (2026-02-30, 2026-13-01, 2026-04-31) with a valid Last checked: date in the section derives a record stamped at the Last-checked (or freshest valid) date, and the record passes
isSnapshotRecord. - A ¥ line carrying an impossible date and no other valid date in the section yields no record (fail-soft, as today for dateless lines).
- Existing behavior is unchanged for a real on-line date and for the no-date fallback (existing DeepSeek tests in
test/snapshot-writers.test.tsstill pass). - New tests cover both impossible-date cases above.
Distinct from: #2568 (recordsFromProviderUsage percent range-check, different function), #2493 (github-billing impossible dates, different pipeline), #3365/#3364 (rollup/census gates).
Activity
developing-today commentedon Nov 1, 2026
CODE-1280
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed
recordsFromDeepseekBalance(pm-stack/aggregator/src/snapshot-records.ts:182) takes the ¥ line's first date-shaped string unchecked, so an impossible date (2026-02-30 / 2026-13-01) shadows the section's valid Last-checked date, the derived record failsisSnapshotRecord, andSnapshotStore.appenddrops it silently (backfill counts it as "already present"). Verified on main e6577a9 with a laptop probe (probe-2026-11-01-laneA-deepseekdate, real snapshot-records.ts sha256 dc4d2b62… identical on both clones): control real date passes the gate, both impossible dates produce gate-failing records, no-date fallback correctly uses Last checked. Distinct from 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, aggregator(github-billing): billing items never validated — an impossible date discards the whole month's collection, negative amounts are stored as usage #2493, aggregator(snapshots): isSnapshotRollup re-admits the shapes isSnapshotRecord was hardened to refuse — impossible dates, negative/string limit, unparseable resetsAt, inverted pairs expand into the reading path unchecked #3365/aggregator(coverage): isRepoCensus accepts impossible census rows — negative counts, gate counts above the open total, '/' repos and silent duplicate overwrite — and they persist into the weekly snapshot baseline #3364. Enqueued as a repo-task/v1 packet on repo-health-code-pilot.19 remaining items
dezren39 commentedon Nov 2, 2026
Parked: OpenChamber scheduled lane parked task 5994 for 20 minutes — CI pending on the owning session PR #4418.
a8a09bdaf(worktree/origin/PR head in sync, clean); only CodeRabbit NEUTRAL reported, CI otherwise pending. No parallel work; nothing pushed or edited. Labels now reflect parked state;work/assignedremains set.dezren39 commentedon Nov 2, 2026
🤖 Agent note · picked up
Merge pull request #4418 from developing-today/queue/5994-3379-deepse…
dezren39 commentedon Nov 2, 2026
🤖 Agent note · done