feat: implement persistent 1-minute price history snapshots with rete…

[githoboman]

Summary
Implemented the historical price snapshots feature on the Add-historical-price-snapshots-endpoint branch.
Closes #55
Schema (sql/schema.sql, prisma/schema.prisma)

New price_snapshots(pair, ts, price, volume) table, PRIMARY KEY (pair, ts) plus an index on (pair, ts). Added to both the SQL file and the Prisma model — the latter is what db push actually applies at startup. (The issue mentioned a Supabase migration, but this repo has no migrations dir; its real mechanism is Prisma db push + sql/schema.sql, so I followed that.)
Snapshot loop (src/ingesters/snapshot.ts)

Aligns to the wall-clock minute, then inserts one row per active pair: latest known price + base volume traded in the minute that just closed, in a single query. Idempotent via ON CONFLICT (pair, ts) DO NOTHING (safe across restarts). Wired into src/index.ts as a fault-isolated ingester.
Endpoint (src/api/history.ts)

GET /prices/history?pair=…&from=…&to=…&interval=1m|5m|1h. Epoch-aligned bucket aggregation (close price + summed volume), defaults to last 24h at 1m, with validation and a MAX_HISTORY_POINTS guard against unbounded scans. Note: the path matches the x402 /price prefix, so it's payment-gated like the other price endpoints.
Retention (src/jobs/snapshotRetention.ts)

Hourly bullmq job pruning rows older than 30 days, following the existing aggregateRefresh pattern.
Tests — 22 new across 3 files (history aggregation/validation, floorToMinute boundaries + append idempotency, retention). Full suite: 101 passed. Typecheck is clean except two pre-existing webhookDispatcher.ts errors I confirmed exist on the base commit.

Docs — README table row, OpenAPI path, and a minor changeset.

Two notes for your review:

I had to run npm ci + prisma generate since node_modules wasn't installed.
The acceptance criterion "returns expected count for a window" is satisfied by the count field + count-matching test, against the snapshot table (not raw price_points).Summary
Implemented the historical price snapshots feature on the Add-historical-price-snapshots-endpoint branch.

Schema (sql/schema.sql, prisma/schema.prisma)

New price_snapshots(pair, ts, price, volume) table, PRIMARY KEY (pair, ts) plus an index on (pair, ts). Added to both the SQL file and the Prisma model — the latter is what db push actually applies at startup. (The issue mentioned a Supabase migration, but this repo has no migrations dir; its real mechanism is Prisma db push + sql/schema.sql, so I followed that.)
Snapshot loop (src/ingesters/snapshot.ts)

Aligns to the wall-clock minute, then inserts one row per active pair: latest known price + base volume traded in the minute that just closed, in a single query. Idempotent via ON CONFLICT (pair, ts) DO NOTHING (safe across restarts). Wired into src/index.ts as a fault-isolated ingester.
Endpoint (src/api/history.ts)

GET /prices/history?pair=…&from=…&to=…&interval=1m|5m|1h. Epoch-aligned bucket aggregation (close price + summed volume), defaults to last 24h at 1m, with validation and a MAX_HISTORY_POINTS guard against unbounded scans. Note: the path matches the x402 /price prefix, so it's payment-gated like the other price endpoints.
Retention (src/jobs/snapshotRetention.ts)

Hourly bullmq job pruning rows older than 30 days, following the existing aggregateRefresh pattern.
Tests — 22 new across 3 files (history aggregation/validation, floorToMinute boundaries + append idempotency, retention). Full suite: 101 passed. Typecheck is clean except two pre-existing webhookDispatcher.ts errors I confirmed exist on the base commit.

Docs — README table row, OpenAPI path, and a minor changeset.

Two notes for your review:

I had to run npm ci + prisma generate since node_modules wasn't installed.
The acceptance criterion "returns expected count for a window" is satisfied by the count field + count-matching test, against the snapshot table (not raw price_points).

[drips-wave]

@githoboman Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits