/chart/:mint cache key includes user-controlled limit parameter — upstream GeckoTerminal amplification

[v1ktorrr0x]

Bug

The limit query parameter (1–500) is included in the in-process cache key for /chart/:mint but has no effect on either upstream call made on a cache miss. Cycling through limit values generates distinct cache keys that all miss, each firing two upstream GeckoTerminal requests.

Source

src/routes/chart.ts

178    const limit = Math.min(500, Math.max(1, ...));
181    const cacheKey = `${mint}:${timeframe}:${aggregate}:${limit}`;
192    const poolAddress = await getTopPool(mint);     // does not depend on limit
202    const candles = await fetchOhlcv(poolAddress, timeframe, aggregate, limit);

limit=1..500 for one mint → up to 500 distinct cache keys → 500 cache misses → up to 1,000 GeckoTerminal calls. GeckoTerminal is consumed without an API key and is IP-rate-limited on egress. Exhausting the egress quota breaks the chart feature for all users.

getTopPool(mint) is the most wasteful part: it depends only on mint but re-runs for every timeframe/aggregate/limit permutation.

Fix

Cache getTopPool(mint) keyed by mint alone in a separate short-TTL cache. Fetch OHLCV at a fixed maximum and slice to limit in-process, so limit never participates in an upstream call or cache key. Alternatively, quantize limit to a small set of buckets (e.g. 50, 100, 200, 500).

Verification

GET /chart/<mint>?limit=1 then ?limit=2 → today: two upstream call pairs. After fix: one pair total, both served from cache.