Revert "Fetch uncached V3 pools on demand so cold quotes find liquidity (#4560)"

[jmg-duarte]

Description

The original PR led to fetch_liquidity taking orders of magnitude more than usual on service restarts. When performing tests this becomes particularly bad because of the deployment neighboring nature.

Changes

• Reverts commit 8cb2626.

How to test

Tested in prod, notice how the spikes disappear

[claude]

Claude finished @jmg-duarte's task in 2m 10s —— View job

---

PR Review: Revert V3 on-demand pool fetching

• Gather context (read diff, original commit 8cb2626)
• Verify the revert is clean and complete
• Review correctness of reverted code
• Post findings

Verdict: ✅ Clean revert, no blocking issues

This is a mechanically sound revert of #4560. Key checks:

• Intermediate commit preserved. Between the original and this revert, Drop the pool-indexer wait-until-timeout config #4561 (2317b58e, drop wait-until-timeout) also touched pool_indexer.rs. The revert correctly keeps that change — it restores the wait_until / get_registered_pools / get_pools_with_ticks_by_ids signatures to u64 while retaining the WAIT_UNTIL_TIMEOUT constant rather than re-introducing the removed wait_until_timeout field. 👍
• No dangling references. The BlockTarget enum and its resolve_block helper are fully removed; a repo-wide search finds zero remaining references. All call sites (pool_fetching.rs:157/199/279) consistently pass u64 (block_number / fetched_block_number), matching the reverted trait signatures.
• Behavior restored. PoolsCheckpointHandler::get goes back to returning cache hits and flagging misses into missing_pools for the next maintenance tick; fetch no longer performs on-demand pool fetching — which is exactly the intent, since the on-demand path was what caused fetch_liquidity to spike on restart.
• get_pools_with_ticks_by_ids empty-ids guard is removed from both sources, restoring the pre-Fetch uncached V3 pools on demand so cold quotes find liquidity #4560 state (no functional regression — this matches the previously-shipped behavior).

The prod graphs in the description confirm the spikes disappear after the revert, which aligns with removing the synchronous on-demand fetch from the quote hot path.

Note

I could not run cargo check / cargo nextest in this environment (command approval not granted), so compilation and the test suite were not executed here. Given the revert is mechanical and the symbol analysis is consistent, I'd expect CI to pass — worth confirming the green check before merging.
• jmgd/revert-caches

[AryanGodara]

LGTM. Looks safe to merge w/o affecting existing running indexers in staging 🫡