[peachbits]

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

none

Description

priceChangeDaemon on push2 has been fetching rates from https://rates2-us1.edge.app, a host that no longer exists. Because ratesCache never cached a failed fetch, every price-change event in every loop retried it and logged a full stack trace: about 17 GB of priceChangeDaemon.log a day, which filled the server's disk to 97% on 2026-10-21. Price-change alerts were not being sent.

Part 1: stop the flood (first two commits). The cache treats a failed fetch like a missing rate for that 5-minute bucket, so the other events in the bucket skip instead of retrying, and logs one warning per bucket that names the configured ratesServer, so a wrong host shows up in a single line. The next bucket tries the server again. A non-2xx reply (the rates load balancer answers 429 with an empty body when a client exceeds 300 requests per 100 s) is reported as HTTP 429 from <ratesServer> instead of invalid json response body. makeRatesCache takes the fetch function as a parameter so the cache can be unit-tested without the network.

The wrong host itself is a config problem, fixed separately by pointing ratesServer in the push-settings/services document back at https://rates2.edge.app (the code's own default). After that change, production showed the second half of the problem: a loop over the ~50,000 price-change events wants about 7,000 distinct (currency pair, 5-minute bucket) lookups, one GET /v2/exchangeRate each, and the load balancer rate-limited most of them, so most alerts were still skipped.

Part 2: batch the lookups (remaining commits). Both price daemons now read the event stream in pages of 500, work out every rate the page will ask for, and fetch the ones not yet cached through POST /v2/exchangeRates in chunks of at most 100, no faster than two requests a second. The per-event logic is unchanged and reads from the cache. A price-change loop makes about 70 requests instead of 7,000; the price-level loop about 24.

• RatesCache.prefetch(requests) skips cached keys, de-duplicates, chunks at 100 grouped by bucket, and matches replies by (pair, date) with a positional fallback, since the live server answers in request order but does not document it. A failed chunk (429, network error, bad JSON) caches null for all of its keys and logs once per bucket. getRate still does a single GET for a key that was never prefetched, as a safety net.
• priceChangeLookups(event, now) and checkPriceChange share priceChangeFromTime, so the prefetch cannot drift from what the check asks for; priceLevelLookups(event, now) walks nested all/any triggers the way checkTrigger does. checkPriceChange moved to src/util/priceChange.ts so it can be tested (the daemon file runs runDaemon() at import).
• now is taken once per page rather than once per event, so a 5-minute boundary mid-page cannot push the rest of the page onto the safety net. event.triggered can be stamped a few seconds early for a send late in a page.
• Each loop ends with one Rates lookups info line: requests, batches, failedBatches, nullRates, singleFetches. After deploy, expect roughly 70 batches, 0 failed and about 0 single fetches per price-change loop.

Tests: 95 passing with a fake fetch and an injected sleep, no network. test/ratesCache.test.ts covers dedupe, cached-key skipping, the 100-item cap and request bodies, in-order, shuffled, re-dated, short and unrelated replies, null rates, rejected batches (429, network error, HTML body) with one warning per bucket and no retries, pacing (three chunks, two sleeps, also across calls) and the counters. test/priceChange.test.ts pins the from-time for every triggered case against what checkPriceChange requests, plus a threshold send. test/triggers.test.ts does the same for nested price-level triggers. test/pages.test.ts covers full, short and empty pages and lazy pulling. eslint, tsc and the sucrase build pass on Node 24; the server runs on Node 16 today and the change uses nothing newer.

Rollout: deploy to push2, start priceLevelDaemon first and watch two loops' Rates lookups lines, then priceChangeDaemon.

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.