Data Source Migration
#1 Why I Had to Stop Using FMP v2/v3 and Move to Stable Endpoints
· Build Log
Endpoint-family mismatch caused production instability, then a stable-only architecture fixed render reliability.
FMP stable endpointmarket data reliabilityworker normalization
1) TL;DR
- Mixed FMP endpoint families created inconsistent payloads and outages.
- One response contract could not safely parse every branch.
- Stable-only routing plus normalization removed blank states.
2) What I Tried
I initially mixed v2/v3 and stable endpoints in one worker route for wider coverage.
3) What Broke
Widgets intermittently rendered empty cards or stale numbers in the same session.
4) Root Cause
Different endpoint contracts, plan compatibility, and rate-limit behavior collided in one execution path.
5) Before (Code Path)
worker/worker.js
- fetchQuote() touched mixed endpoint families
- renderer assumed one schema
- cache keys were not endpoint-contract aware
6) After (Code Path)
worker/worker.js
+ stable endpoint family as primary contract
+ normalizeQuote() before rendering
+ stale fallback branch for transient failures
7) Evidence (Git History)
- d640d4a fix(worker): migrate historical endpoints to /stable path.
- 0c115a9 fix(news): enforce JSON mode and stable Gemini fallbacks.
- 78527b3 fix(main): preserve OCR journal data and stabilize dependent widgets.
8) What I Learned
Reliability improves when one strict data contract is enforced before caching and rendering.
9) Frequently Asked Questions
Why not keep all endpoint families in parallel?
Contract divergence creates hidden parsing faults and unstable cache behavior under load.
What made the fix durable?
Normalization before UI render and stale fallback after live-call failure.
Was this mainly performance work?
It was stability-first; performance improved as a side effect.