meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56

meta-exporter: `parsePaygBalance` silently truncates any balance whose decimals aren't exactly two — "$1,234.5" exports 1234 and "$1,234.567" exports 1234.56

Evidence (verified this run, main `5a34fa70`)

pm-stack/meta-exporter/meta-quota-export.mjs, parsePaygBalance (lines 113–119):

const m = iframeText.match(/Current balance\s*\n?\s*\$\s*([\d,]+(?:\.\d{2})?)/);

The capture is not anchored at the end of the amount: the regex matches a prefix of a longer number and returns it as the balance.

Probe (node, importing the real module from main):

iframe text	exported `paygBalanceUsd`
`Current balance\n$1,234.56`	`1234.56` ✅ (existing test case)
`Current balance\n$1,234.5`	`1234` — the `.5` is silently dropped
`Current balance\n$1,234.567`	`1234.56` — the third decimal is silently dropped

Why it matters

The function's own documented contract is that a balance it cannot read stays null — "an absent read must stay absent, never become a fake $0." A truncated balance is a fake value of exactly the same kind: if the billing page's format drifts (one decimal shown, a trailing digit group, a different rounding), the exporter publishes a wrong — always lower — PAYG balance as a measured fact in a status: "ok" document, and the quota gatherer (#1151) ingests it. Returning null on anything that isn't a clean, fully-consumed amount preserves the fail-closed design; silently truncating does not.

Acceptance criteria

parsePaygBalance returns the exact value only when the amount is consumed completely; a digit or decimal point immediately following the matched amount makes the read null (amount-ending boundary pinned by triage — e.g. a negative lookahead or an explicit end anchor that still tolerates the text that follows the balance on the real page).
New tests in meta-quota-export.test.mjs: "$1,234.5" → null; "$1,234.567" → null; the existing cases ($0.00 → 0, $1,234.56 → 1234.56, no-match → null, non-string → null) still pass (node --test pm-stack/meta-exporter/).

Dedup

#2175 (CDP timeouts), #2350 (entry-point check), #1566 (closed, window_duration_secs) are distinct mechanisms. Sibling filed this run: #2460 (subscription-quota epoch range validation — different function, different mechanism).

CODE-1258

🤖 Agent note · filed

Agent: new-issue-creator-code-b
Session / ID: new-issue-creator-code-b cron run 2026-10-29 18:20 CDT
Found via: filed this run
Task: Filed the meta-exporter PAYG truncation flaw: parsePaygBalance (meta-quota-export.mjs:115) matches an unanchored amount prefix, so "$1,234.5" exports 1234 and "$1,234.567" exports 1234.56 instead of returning null — violating the function's own contract that an unreadable balance stays absent, never a fake value. Verified with node against the real module on main 5a34fa7 (both truncations reproduced; the existing $1,234.56 case stays exact).
Expectation: effort xs; done when triage pins the amount-ending boundary and routes a small_fix packet with the named regression tests ($1,234.5 → null, $1,234.567 → null, existing cases unchanged).
Links: meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56 #2461 meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56 #2461 · sibling filed this run meta-exporter: subscription-quota timestamps are never range-checked — an ms-scale resets_at exports a year-58790 reset as a successful reading, and an out-of-Date-range value throws a bare RangeError misclassified as fetch-failed #2460 (quota epoch validation, different function/mechanism) · meta-exporter: CDP plumbing has no timeout — an endpoint that accepts but never answers hangs the exporter forever and writes no failure document #2175/meta-exporter: meta-quota-export still uses the pre-#2083 raw-path entry-point check — invoked via any symlink it silently no-ops with exit 0 #2350 distinct

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), OpenChamber scheduled lane
Session / ID: queue task 5605 (small_fix)
Found via: queue claim; canonical fix task from triage 5557
Task: Implement the validated amount-ending boundary in parsePaygBalance and add the two malformed-decimal regressions; preserve the comma-backtracking guard and valid trailing-page-text cases.
Expectation: done = focused tests pass and fix is merged, or PR opened and parked if CI remains pending.
Links: meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56 #2461 · triage task 5557 · canonical dedupe repo-health:v1:fix:developing-today/code:issue:2461

🤖 Agent note · PR opened

Agent: queue worker (repo-worker-code), OpenChamber scheduled lane
Session / ID: queue task 5605
Branch: queue/5605-2461-reject-truncated-payg · commit 6313cd8
PR: fix(meta-exporter): reject truncated PAYG balances (#2461) #3697
Change: the amount regex now blocks following digits, commas, and decimal points, preventing silent truncation and comma-backtracking; tests cover malformed decimals, valid integers/amounts, and trailing page text.
Validation: node --test pm-stack/meta-exporter/*.test.mjs — 18/18 pass; git diff --check passes.
Next: checking CI and review state; will merge if all gates pass or park if CI is pending.

Merge pull request #3697 from developing-today/queue/5605-2461-reject…

🤖 Agent note · done (already merged)

Agent: OpenChamber scheduled lane (repo-worker-code)
Session / ID: queue task 5605 (resumed from merge_ready)
Found via: atomic queue claim
Task: Resume the verified meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56 #2461 fix from its merge-ready checkpoint and close the queue task.
Outcome: Fresh GitHub state showed meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56 #2461 CLOSED and PR fix(meta-exporter): reject truncated PAYG balances (#2461) #3697 MERGED before further action. Merge commit: bda855c. Checks SUCCESS; prior targeted tests 18/18 and diff check pass. No duplicate merge or code changes. Cleared stale in-progress queue labels.
Links: PR fix(meta-exporter): reject truncated PAYG balances (#2461) #3697; queue task 5605

Navigation Menu

Repository navigation

meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56 #2461

meta-exporter: `parsePaygBalance` silently truncates any balance whose decimals aren't exactly two — "$1,234.5" exports 1234 and "$1,234.567" exports 1234.56

Evidence (verified this run, main `5a34fa70`)

Why it matters

Acceptance criteria

Dedup

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — '$1,234.5' exports 1234 and '$1,234.567' exports 1234.56 #2461

Description

meta-exporter: parsePaygBalance silently truncates any balance whose decimals aren't exactly two — "$1,234.5" exports 1234 and "$1,234.567" exports 1234.56

Evidence (verified this run, main 5a34fa70)

Why it matters

Acceptance criteria

Dedup

Activity

developing-today commented on Oct 29, 2026

dezren39 commented on Oct 29, 2026

19 remaining items

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

meta-exporter: `parsePaygBalance` silently truncates any balance whose decimals aren't exactly two — "$1,234.5" exports 1234 and "$1,234.567" exports 1234.56

Evidence (verified this run, main `5a34fa70`)