fix: one dead subgraph no longer wipes out all payment data

[rodrigopavezi]

One unavailable subgraph currently destroys all payment data. Stacked on #116.

On #114 — do not merge it first

This touches the same six files as #114 (xdai → gnosis, mainnet → ethereum). I originally suggested merging #114 first to avoid conflicts. Having read it, I withdraw that.

#114 renames the Hasura remote-schema names inside the GraphQL documents (payment_xdai → payment_gnosis, payment_mainnet → payment_ethereum). Production evidence says those remotes are still payment_xdai/payment_mainnet: the SRF validation error in the console today lists both in the query text and Hasura rejects only payment_zksyncera's inner field — and Hasura validates the whole document, so an unknown top-level field would have been reported too.

So merging #114 as-is would take payment data from "broken on one chain" to "broken on every chain". Details and a suggested identifier-only fix are in a comment on #114. This PR does not need to wait for it.

The problem, live in production right now

The payment and SRF queries were single GraphQL documents aliasing 11-14 chain remotes at once. Hasura returns data: null when any one remote errors, so a single unavailable chain destroyed the entire result:

fetchRequestPayments Error: subgraph not found: no allocations
field 'singleRequestProxyDeployments' not found in type: 'payment_zksynceraQuery'

Confirmed by loading the site: /payments renders completely empty, "Recent payments" shows "No data", and every request page reports Balance: 0 no matter what was actually paid. Thirteen healthy chains were being discarded because of one.

For actual users this is worse than the 500 in #116 — an explorer that reports every request as unpaid.

The fix

Each fan-out is now one request per chain via Promise.allSettled, merged through the existing unchanged formatters. A rejected chain is skipped and logged with its name; healthy chains still return data. Only a total failure of every chain throws — a full outage must not be indistinguishable from "no results", and #116's error states surface it.

Output is byte-identical when all chains are healthy.

One thing worth knowing, preserved rather than "fixed": today's behaviour is already per-chain top-N, not global top-N — first: 10 across 14 chains can return 140 rows, because the formatters merge and sort but never apply a global slice. Changing that would alter visible row counts and pagination, so it deserves its own decision rather than riding along here.

Also here

• Dropped payment_zksyncera from the SRF queries only — that subgraph genuinely lacks the singleRequestProxyDeployments entity, so querying it could only ever error. Expressed as data in consts.ts via the pre-existing but unused PAYMENT_CHAINS enum. Note SRF_CHAIN_REMOTES is not "all chains minus zksyncera": the SRF queries never covered fantom, fuse or moonbeam, so an explicit list was the only way to preserve today's coverage exactly.
• hooks/payments.ts was a byte-for-byte duplicate of queries/payments.ts whose fetchPayments swallowed errors and returned [], making failure indistinguishable from empty at the query layer. Nothing imports it; it is now a thin re-export rather than a second copy of the same bug.
• A CI smoke check that actually serves the app and requests /request/<id>, failing on 5xx. This is the signal that was missing for fix: stop every /request/<id> URL returning HTTP 500 #116's bug: next build only compiles that route, npm run check is formatting only, and there are no tests. Dummy env, no secrets, polls for readiness rather than sleeping.

Trade-off, accepted deliberately

Up to 14 parallel HTTP round-trips per logical query instead of 1. revalidate: 60 and Hasura's @cached blunt it, and no batching layer or dependency was added. Worth watching Hasura rate limits.

Not addressed

• queries/transactions.ts and address-transactions.ts have the identical fragility against the two storage remotes — if storage_sepolia is down, mainnet requests vanish too. Left alone to keep this diff scoped; they need the same treatment.
• Restoring the missing subgraph is upstream indexer work, not a change in this repo (likely payments-subgraph / indexer allocations). This PR stops one dead chain from zeroing the UI; it does not bring the data back. Balance: 0 will persist until the subgraph is served again.

Verification

npm run build ✅, tsc --noEmit clean, biome clean, built query documents validated through graphql.parse. Not verified: happy-path merge against live data — the local Hasura URL is a stand-in, so this is verified by construction and by its degradation behaviour, not against production data.

[rodrigopavezi]

• feat: server-render the request page so crawlers get the request #118
• fix: one dead subgraph no longer wipes out all payment data #117 👈 (View in Graphite)
• fix: stop every /request/<id> URL returning HTTP 500 #116
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Greptile Summary

The PR isolates remote-schema failures so healthy chains continue returning payment and channel data.

• Replaces multi-remote GraphQL documents with per-chain requests merged through existing formatters.
• Excludes zkSync Era from SRF queries and consolidates the duplicate payments hook behind a re-export.
• Adds unit coverage for partial and total fan-out failures plus a dynamic-route smoke check in CI.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/lib/queries/utils.ts	Adds the shared all-settled fan-out helper that preserves successful chain results and throws on total failure.
src/lib/queries/utils.test.ts	Covers successful merging, partial rejection, missing buckets, total failure, and empty chain lists.
src/lib/queries/payments.ts	Converts the payment listing query to one request per configured payment remote.
src/lib/queries/request-payments.ts	Converts request-specific payment lookup to isolated per-chain requests while preserving empty-reference handling.
src/lib/queries/srf-deployments.ts	Fans SRF lookups across only the remotes that expose the required entity.
src/lib/queries/channel.ts	Queries storage remotes independently and avoids treating uncertain availability as a confirmed missing channel.
.github/workflows/build-and-lint.yml	Runs the new unit suite and verifies that production server routes avoid 5xx responses.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Caller[Payment or SRF fetcher] --> FanOut[requestPerChain]
  FanOut --> C1[Chain request 1]
  FanOut --> C2[Chain request 2]
  FanOut --> CN[Chain request N]
  C1 --> Merge[Merge fulfilled results]
  C2 --> Merge
  CN --> Merge
  Merge -->|At least one succeeds| Format[Existing formatter]
  Merge -->|Every chain fails| Error[Propagate outage error]
  Format --> UI[Partial or complete data]

Loading

_{Reviews (4): Last reviewed commit: "test: cover the per-chain merge behaviou..." | Re-trigger Greptile}

[rodrigopavezi]

Fair, and accepted as a real limitation rather than fixed — here's the honest state of it.

The smoke check was built to catch the class of bug in #116: a module-scope import throwing under Node, which turned every /request/<id> into a 500 for months while CI stayed green. It does that. You're right that it cannot see a regression in the per-chain merge logic, because it only inspects HTTP status.

I tried to close the gap with a unit test of requestPerChain and backed it out. Three concrete blockers, all worth knowing:

1. No TypeScript test runner is available. tsx is not a devDependency here (I'd misremembered it from another repo). Node 20 — the version CI pins — has no built-in TS support; --experimental-strip-types is 22.6+.
2. Importing the real module throws under plain Node. graphQlClient.ts calls React's cache() at module scope, and the installed react@18.3.1 doesn't export cache. That only works because Next aliases react to its own bundled fork. So any test that imports the module under a stock runtime dies on load.
3. graphql-request v7 is ESM-only, so a plain tsc-to-CommonJS path fails on that import too.

A working version existed, but it needed a ~900-character node -e bootstrap in package.json that monkey-patched Module._load and require.extensions. It passed, and it correctly went red when I deliberately broke the skip-a-failed-chain behaviour — but I'm not going to ask anyone to maintain that, and it's a lot of machinery for one advisory comment.

Doing this properly means adding a test runner (vitest is the obvious pick — handles TS, ESM and module mocking natively, one devDependency) and that is a tooling decision for this repo, not something to slip into a bug-fix PR. This repo currently has zero tests, so there's no convention to follow either.

Happy to add it in a follow-up PR if you want it — say the word. Worth noting either way that a CI unit test still wouldn't cover live merge behaviour against real subgraphs; that needs a mock backend in CI, which is a larger piece of work again.

[rodrigopavezi]

Fixed properly — I'd previously argued this was out of scope, and that call was overridden, so here it is with real coverage.

Added vitest and five tests for requestPerChain, covering the behaviours whose regression would otherwise be invisible:

Behaviour	Expected
Every chain succeeds	one entry per chain in the merged result
One chain rejects	skipped, others survive, no throw
One resolves with no bucket	treated as a failure, still no throw
Every chain fails	throws, naming the failed chains
Empty chain list	does not throw

Rows 2 and 4 are the load-bearing ones — the entire point of the per-chain split is that one dead subgraph stops wiping out the other thirteen, and that a total outage stays distinguishable from "there is no data".

I verified the tests can actually fail, twice and in different ways, because a test that can't fail would just recreate the blind spot you're reporting:

• Making a rejected chain merge in as an empty bucket → reds the skip test:
  AssertionError: expected { mainnet: {}, polygon: { total: 2 } } to deeply equal { polygon: { total: 2 } }
• Removing the total-failure throw → reds the all-fail test.

Both restored to byte-identical files afterwards, suite green again.

Wired into CI before the smoke test, so a logic regression fails fast and with a clearer signal than a server probe.

One note on why vitest rather than Node's built-in node:test: src/lib/graphQlClient.ts calls React's cache() at module scope, and the installed react@18.3.1 doesn't export it — that only works under Next, which aliases react to its own bundled fork. Any runner that lets the real module execute dies on load. vi.mock prevents it from ever being evaluated. graphql-request v7 is also ESM-only, which vitest handles natively. These are the first tests in this repo, so there was no existing convention to follow.

Being explicit about the remaining limit: this tests the merge logic in isolation, not live behaviour against real subgraphs. Catching that needs a mock backend in CI — a larger piece of work, and worth its own issue if you want it.

[bassgeta]

Looks great, nice job cleaning up all the quirks of Hasura + the subgraphs, nice one 👌

[rodrigopavezi]

Merge activity

• Jul 29, 2:11 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jul 29, 2:13 PM UTC: Graphite rebased this pull request as part of a merge.
• Jul 29, 2:13 PM UTC: @rodrigopavezi merged this pull request with Graphite.