fix(remote): arm the statistics floor on delivery, not on the attempt

[veksen]

Rebased onto main now that #229 has merged. The diff is the three files below.

Goal

A project's production statistics should refresh at least daily, so CI costs a run against numbers that match production. The site project has gone five days without a capture, and a docs-only PR failed CI with nine cost regressions its diff did not cause.

This PR stops a lost push from being recorded as delivered. It is one of several things wrong on that path and it is not the one that silenced captures; see the note at the bottom.

What

Before: a statistics dump that never reached the server was recorded as if it had. The next attempt came 24 hours later, and so did the one after that.

After: the daily floor advances only when the server accepts the dump. A push lost to a dropped socket takes the existing 15-minute backoff and is retried.

How

Read src/remote/remote.ts first. applyStatistics set lastStatsPushAt and then emitted statsApplied; the listener in api-client.ts pushes over a fire-and-forget pushStats whose rejection was only logged. Arming on the attempt made a dropped push indistinguishable from a stored one. The field's own comment already claimed it "only advances on success", so this makes the code match what it said.

markStatsPushed and markStatsPushFailed are the new seam. Only the api-client knows whether the server took the dump, so it reports the outcome back rather than the emit assuming it.

refreshStatsIfStale no longer clears retryStatsAfter after a successful dump. The push it starts settles a microtask later, so clearing it there wiped the backoff that a failed push had just set, and the next poll re-dumped immediately. The regression test caught this on its first run.

The drift baseline still moves at apply time. It records what this analyzer dumped rather than what the server stored, and rolling it back on a failed push would re-trigger Size Drift on every poll.

Tests

src/remote/stats-push-delivery.test.ts drives the real wiring: a fake pushStats through hookUpApiReporter against a real Remote.

The load-bearing case calls refreshStatsIfStale three times and counts dumps — once when the floor is due, once immediately after the lost push, once after the backoff lapses. Asserting on the floor field alone would stay green while the analyzer sat silent for a day, which is the actual symptom.

Verified as a regression test by restoring the old arming line: three of the five cases fail, including "expected dumpSourceStats to be called 2 times, but got 1".

Full suite passes. npm run typecheck and npm run build are clean.

What this does not fix

Captures stopped because Size Drift went quiet, not because a push was lost. The 2026-08-07 08:38 capture recorded project_queries at 6,186 rows, the high side of an estimate that swings because the table is bloated. Drift measures movement against the baseline as denominator with a 0.5 ratio, and from 6,186 the low side is a 42% drop. Computed against live pg_class, the largest mover is 41.6% and the verdict is not drifted.

That leaves the daily floor as the only trigger, and analyzer logs from 2026-08-11 show it never fired on a container that had been up for four days. Why is still open.

[github-actions]

Query Doctor — 6 successful checks

 Cost regression — No query went up more than 5%
 Untested data access — No changed data-access file without a test
 New query — No new queries
 New query with index recommendation — No new query ships an index recommendation
 Schema drift — No schema changes
 High-value nudge — No index or rewrite past the threshold

---

_{More details via MCP → get_ci_run({ runId: "019ff8d6-466b-79f4-b9a5-5fcd3e148288" }) · view run · docs
3 queries read against main on assumed statistics of 10,000,000 rows per table. Sync production stats for costs measured against your real data.}