Remove now unsused v3 subgraph source

[AryanGodara]

Description

Every V3 network (prod + staging) already reads liquidity from the pool-indexer, so the driver-side subgraph-vs-indexer is no longer needed. This makes the pool-indexer the only Uniswap V3 liquidity source.

Stacked on #4733

Changes

• delete UniV3SubgraphClient and its GraphQL queries; rename graph_api.rs → models.rs, keeping only the plain pool/tick DTOs.
• Remove the fetch_on_demand guard. It's always on now that the indexer is the only source.
• Collapse the driver's UniswapV3PoolSource enum and the IndexerConfig::Subgraph variant down to the single pool-indexer form.
• Drop the now-unused max_pools_per_tick_query from the shared subgraph client (V3 tick-chunking was its only reader; Balancer always passed usize::MAX).
• Remove the dead LiquidityProvider::UniswapV3 e2e helper (never constructed since it was introduced in UniV3 support in the Baseline solver #3468, so safe to remove).

How to test

• unit and e2e tests

Note before merge

The shadow envs for 2 networks still use the subgraphs, so they need to be pointed to use the staging pool indexers first. I'll open the respective PR there, before merging in this one.

[AryanGodara]

@claude review this

[claude]

Claude finished @AryanGodara's task in 2m 11s —— View job

---

PR Review

• Read PR diff against base branch
• Review changed files
• Verify no leftover references / behavior changes
• Post summary

Verdict: LGTM ✅ — clean, correct deletion refactor. No blocking issues found.

I traced each claimed simplification and they all hold:

• No dangling references. Grepped the whole workspace for UniV3SubgraphClient, UniswapV3PoolSource, UniswapV3Subgraph, max_pools_per_tick_query, fetch_on_demand, IndexerConfig::Subgraph, and uniswap_v3::graph_api — all gone.
• Model migration is faithful. graph_api.rs → models.rs correctly drops the now-unneeded Deserialize / #[serde(rename_all)] / HexOrDecimalU256 attributes (the pool-indexer constructs these DTOs directly via into_pool_data / into_tick_data rather than deserializing them), while Token keeps its Serialize derive that the baseline solver needs. balancer_v2::graph_api is a separate module and is untouched aside from dropping the usize::MAX arg.
• Behavior-preserving. Removing the fetch_on_demand gate is a no-op: the indexer's fetch_on_demand() always returned true, so fetch_missing_on_demand behaves identically. Dropping max_pools_per_tick_query is safe — the V3 tick-chunking was its only reader and Balancer always passed usize::MAX.
• No in-repo config breakage. example.toml is the only uniswap-v3 config in the repo and it's updated; there are no checked-in configs using the removed { subgraph = ... } form that would fail deny_unknown_fields. (The external shadow-env migration is already called out in the PR description as a pre-merge step.)

A couple of things I considered and deliberately did not flag:

• Keeping IndexerConfig as a single-variant enum (rather than collapsing to a struct) is the right call — it preserves the indexer-config = { pool-indexer = { ... } } TOML shape so deployed configs don't need to change.
• The irrefutable let file::IndexerConfig::PoolIndexer { url } = indexer_config; in load.rs is fine and idiomatic for a single-variant enum.

Note: I was unable to run cargo check/clippy in this environment (command not permitted), so compilation rests on CI — but the changes are mechanical and self-consistent on inspection.
· aryan/remove-v3-subgraph-source

[claude]

Claude finished @AryanGodara's task in 2m 1s —— View job

---

PR Review

• Read PR diff against base branch (origin/aryan/be-36-pool-indexer-onchain-seed)
• Review changed files
• Verify no leftover references / behavior changes
• Post review

Verdict: LGTM ✅ — clean, behavior-preserving deletion refactor. No blocking issues; nothing warranting an inline comment.

What I verified beyond a re-read of the diff:

• No dangling references. Grepped the workspace for every removed symbol (UniV3SubgraphClient, UniswapV3PoolSource, UniswapV3Subgraph, max_pools_per_tick_query, fetch_on_demand, IndexerConfig::Subgraph, LiquidityProvider::UniswapV3) — all gone. All callers of the changed signatures (UniswapV3PoolFetcher::new, PoolsCheckpointHandler::new, SubgraphClient::try_new) are updated.
• models.rs migration is faithful. Compared derives against the deleted graph_api.rs: DTOs that are now built directly via into_pool_data/into_tick_data correctly drop Deserialize/serde_as/HexOrDecimalU256, while Token keeps Serialize for the baseline solver. The dropped #[serde(rename_all = "camelCase")] on Token is a no-op (its fields id/decimals are single words), so serialized output is unchanged.
• Behavior-preserving guard removal. fetch_on_demand was always true for the indexer, so fetch_missing_on_demand behaves identically. Dropping max_pools_per_tick_query is safe — V3 tick-chunking was its only reader and Balancer always passed usize::MAX.
• No leftover unused imports. anyhow::Context in boundary/liquidity/uniswap/v3.rs is still used (line 132); Arc<PoolIndexerClient> coerces to Arc<dyn V3PoolDataSource> at the UniswapV3PoolFetcher::new call site, so dropping the explicit annotation is fine.
• Config shape. Keeping IndexerConfig as a single-variant enum preserves the indexer-config = { pool-indexer = { ... } } TOML shape, and example.toml is the only in-repo config — updated. The external shadow-env migration is already called out as a pre-merge step.

Couldn't run cargo check/clippy in this environment, so compilation rests on CI — but the changes are mechanical and self-consistent on inspection.
· aryan/remove-v3-subgraph-source

[MartinquaXD]

Do we not have an e2e test that requires this?

[AryanGodara]

No test requires this. I checked at it was never constructed. It was added in #3468 as scaffolding whose e2e testwasremoved (validated on mainnet-staging instead). So this was just hanging around not being used
ref: