[DEV-CHIDIOFFICIAL]

closes #366

[drips-wave]

@DEV-CHIDIOFFICIAL Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

Extracting the pools query into a module both REST and GraphQL call is the right design — two surfaces computing the same answer separately is how they start disagreeing, and we have fixed three instances of exactly that today. It needs a rebase before I can take it, and there is one specific thing to carry across.

The extraction would silently drop exact decimals from /pools

main's REST handler now runs the pools response through the decimal-format negotiation that #542 added (src/api/rest.ts:261):

const decimalFormat = resolveDecimalFormat(req)
if (decimalFormat === 'string') {
  reply.header('x-decimal-format', 'string')
}

src/api/pools.ts has no notion of a decimal format — I grepped it, there is no mention. So moving the query behind getPools() as written would return /pools to doubles for clients that asked for exact strings, and nothing would fail: the numbers would still look right, just with IEEE-754 error back in them. #542 took two rounds of review to get that property, and the reason it is worth protecting is that a wrong total is indistinguishable from a right one at a glance.

So getPools needs to take the format (or return the raw decimal strings and let each caller format), and GraphQL needs to decide what it does with it — most likely always numbers, which is fine as long as it is a decision rather than an accident.

The rest of the rebase

src/api/graphql.ts  3 conflicts,  96 lines
src/api/rest.ts     2 conflicts,  53 lines

Both files moved a long way: graphql.ts gained the oracle types and compareOracles, the query-depth limiter, getActivePairs, and — an hour ago, in #468 — a pairs query with its own Asset and Pair types. rest.ts gained getImpact, listCrashes and the decimals helpers. Your pools query composes with all of it; the imports and the SDL block just need rebasing rather than replacing.

Two things that will save you a round trip:

• schema.graphql is a committed artifact. src/__tests__/graphqlSchemaDrift.test.ts compares it against the code-defined schema, so run npx tsx scripts/generate-graphql-schema.ts after adding the Pool types.
• If you touch openapi.yaml, openapi.json and clients/typescript/src/schema.d.ts are both generated and both guarded in CI.

The 106-line graphqlPools.test.ts is good and should survive as-is. Rebase, npx tsc --noEmit and npx vitest run clean, and I will take it.