fix: two silent pipeline failures — an unpaged candle request and an over-tight discovery pre-filter

[eaitbrahim]

Two independent bugs found while running /keel-asset-scout on 2026-08-16. Both were silent, both had been costing real work, and neither is in the trading core.

1. market_feed never paged under the venue's candle cap

poll_once requested every bar between the last stored candle and now in one call. Coinbase rejects a span over ~350 intervals with a 400 INVALID_ARGUMENT, and the exception propagates out of poll_once — so it doesn't degrade one product, it kills the whole agent cycle for every product.

history.py has paged under this cap since it was written (MAX_CANDLES_PER_REQUEST = 300). Two modules fetch candles; only one knew about the limit — which is exactly why keel fetch always worked while the agent loop died.

Observed in production: ZEC-USD hourly sat 570 bars stale, and ZEC is on the paperforward allowlist. Paperforward failed on its first poll for two consecutive days — 10 failures on 2026-08-14, 12 on 2026-08-15. The other 18 allowlisted products were one bar behind and perfectly healthy. One stale series stopped all of them.

backfill had the same unbounded shape by a different route: _missing_ranges groups missing timestamps into contiguous ranges, and a contiguous range is itself arbitrarily long.

Verified against the live venue, replaying the actual 570-bar gap on a copy of the production DB: 569 candles written across 2 requests of 300 and 269, where main issues a single 570 and 400s.

The existing fakes could not have caught this — they served any span asked for, so they were strictly more permissive than the venue. The new tests use a VenueCappedFakeClient that raises the real 400.

2. The discovery pre-filter was pinned equal to the admission floor

--min-volume-24h defaulted to exactly ScreenPolicy.min_median_daily_volume, with the stated intent that equality kept discovery from being stricter than the criterion it screens for. The intent is right; equality does not achieve it.

The pre-filter reads a one-day venue snapshot; the gate medians volume × close over years. Same units, so they look comparable — wildly different distributions, so an equal threshold gets crossed constantly in both directions by ordinary variation, and about half those crossings hide an asset the gate would have admitted. Nothing reports the exclusion.

On 2026-08-15 a quiet day put five already-attested assets under the floor while their true medians ran 3.08×–6.32× over it. That looked like bad luck. Then a sweep at a lowered floor surfaced three assets that had never appeared in fifteen prior discovery runs:

asset	24h snapshot	vs floor	real gate statistic	vs floor
FIL	413,040	0.41×	3,483,442	3.48×
OP	356,063	0.36×	2,585,626	2.59×
JASMY	301,861	0.30×	4,161,283	4.16×

Not considered and rejected — never seen. A filter that exists only to bound the request count was silently deciding the candidate universe.

The invariant becomes a margin rather than an equality (DISCOVERY_FLOOR_MARGIN = 4), derived from the admission floor rather than restated so the two cannot drift. 4 leaves ~3× headroom below the lowest ratio yet observed on an admissible asset. Cost is bounded: the sweep went from 35 to 82 candidates out of 920 products — still the "cut ~900 to a shortlist" job the filter is for.

test_the_discovery_floor_matches_the_admission_liquidity_floor asserted the equality and so encoded the bug; it now asserts the margin. Also fixes a pin that had already gone stale while looking authoritative — test_build_discover_report_applies_default_volume_floor_matching_assets_discover restated the floor as a literal and its docstring still claimed 5000000 long after the default became 1000000.

Checks

• pytest — 2730 passed, 1 skipped (2727 → 2730)
• ruff check — clean
• mypy keel — clean, 77 source files
• ruff format is not in CI; these files are no worse than main (one is better)

Note for deployment

The running deployment uses the installed package, not this checkout, so paperforward is not fixed by this merge alone. It was unblocked immediately by closing ZEC's gap with keel fetch --products ZEC-USD (which uses the already-correct paging) — but the next series to fall behind will reproduce it until this ships.

🤖 Generated with Claude Code

[eaitbrahim]

Superseded — closing rather than rebasing, deliberately.

I opened this against 29d9b20 without seeing that a concurrent session had already landed the same two fixes, better:

• candle cap — fix(data): chunk poll_once's catch-up request under Coinbase's candle cap #269 (poll_once) and fix(data): chunk the remaining candle-request windows under the venue cap #271 (repair.py, history.py), including an off-by-one in history.py this PR did not catch
• discovery floor — fix(compliance): stop discovery hiding assets the gate would admit #270 and fix(compliance): review follow-ups to #270 — re-pin the admission floor, stop a NaN crash #273, which set it to 100000 (1/10th of the admission floor, vs the 1/4 here), pin it as strictly below rather than equal, and fix a NaN/infinite volume crash this PR does not touch

Rebasing would mean resolving conflicts in favour of the weaker version on both counts, so there is nothing here worth carrying forward on those two fronts.

One thing in this PR was not covered by #269/#271: market_feed.backfill is still unpaged on main. That is now #295, rebased onto current main and scoped to just that site.

For the record, since it may be useful context for #269: the production trigger was ZEC-USD hourly sitting 570 bars stale in keel.db while ZEC was on the paperforward allowlist, which took the cycle down for all 19 products (10 failures 2026-08-14, 12 on 2026-08-15). I closed that gap with keel fetch --products ZEC-USD, so paperforward is unblocked independently of any release.