From 9609271556a151ab5a49b4858e80a91716d051b8 Mon Sep 17 00:00:00 2001 From: Emil Lerch Date: Tue, 30 Jun 2026 12:40:37 -0700 Subject: [PATCH] remove completed todo --- TODO.md | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/TODO.md b/TODO.md index 8ec3c22..7c3df42 100644 --- a/TODO.md +++ b/TODO.md @@ -33,28 +33,6 @@ opts ESPP/HSA accounts into cash-based attribution. Related: ESPP-style accrual blind spot in the "Audit: manual-check accounts mechanism" section above. -## On-demand server-side fetch for new symbols - -Currently the server's SRF endpoints (`/candles`, `/dividends`, etc.) are pure -cache reads - they 404 if the data isn't already on disk. New symbols only get -populated when added to the portfolio and picked up by the next cron refresh. - -Consider: on a cache miss, instead of blocking the HTTP response with a -multi-second provider fetch, kick off an async background fetch (or just -auto-add the symbol to the portfolio) and return 404 as usual. The next -request - or the next cron run - would then have the data. This gives -"instant-ish gratification" for new symbols without the downsides of -synchronous fetch-on-miss (latency, rate limit contention, unbounded cache -growth from arbitrary tickers). - -Note that this process doesn't do anything to eliminate all the API keys -that are necessary for a fully functioning system. A more aggressive view -would be to treat ZFIN_SERVER as a 100% source of record, but that would -introduce some opacity to the process as we wait for candles (for example) to -populate. This could be solved on the server by spawning a thread to fetch the -data, then returning 202 Accepted, which could then be polled client side. Maybe -this is a better long term approach? - ## Infra / performance - **HTTP connection pooling.** Parallel server sync in `loadAllPrices`