feat: server-render the request page so crawlers get the request

[rodrigopavezi]

Makes the request page serve the actual request in its HTML, instead of an empty skeleton. Top of the stack, on #117.

#116 stopped the 500s, but the page still served nothing useful: it fetched on the client, so the HTML was a skeleton with zero request data. For the SEO audit that started this, a 200 with an empty shell is barely better than the 500 it replaced.

page.tsx is now an async server component that awaits fetchRequest and passes the Channel to a new client component, request-details.tsx, which keeps everything genuinely browser-bound: PDF export, the JSON viewer, clipboard buttons, TimeAgo, useState. The relocation is verbatim — same markup, classNames, copy, table structure.

Verified against a local stand-in backend: the served HTML now contains the gateway, payee, payer, expected amount, payment reference, encryption status, and the transactions table. Before, none of it was there.

Plus generateMetadata, so these pages finally have a real title and description for search results and link previews.

Two findings worth reading

json-edit-react cannot be server-rendered

Its theme provider calls document.documentElement.style.setProperty("--jer-highlight-color", …) during render. The moment the details actually server-rendered, that threw ReferenceError: document is not defined, React bailed out to client rendering, and the HTML went straight back to being an empty shell — the twin of #116's bug, hidden until now because SSR had never got as far as rendering this component.

It is now loaded via next/dynamic with ssr: false. The raw JSON blob is not the indexable content, so nothing is lost.

Note this is a render-time touch of document, not an import-time one — which is why an import-level audit of the very same file came back clean. Worth remembering when auditing the next one.

A missing request still returns 200, not 404

It renders the not-found UI, but the status is wrong, and this is a framework limit rather than something left undone.

The route streams (Transfer-Encoding: chunked), so the HTTP status commits when the shell flushes — before the lookup resolves. notFound() can then only swap the rendered UI. Both placements were tried and measured:

Approach	Result
notFound() from the page body	200
notFound() from generateMetadata	200

A real 404 needs the existence check to run before the response commits — i.e. middleware, with a Hasura call on every request. That is a bigger trade than this PR should make unilaterally, so I stopped and flagged it instead.

What I did instead addresses the actual harm: a missing request is served <meta name="robots" content="noindex, nofollow">, which is what stops soft 404s accumulating in the search index. Valid requests are not noindexed — checked both ways.

Implementation notes

• The request lookup is wrapped in React's cache() keyed on the id, so generateMetadata and the page share one network call. The fetch-level cache cannot do this: graphql-request issues a POST, which Next's Data Cache does not dedupe, and the cache() inside graphQlClient is keyed on a fresh RequestInit per call.
• A thrown fetch is deliberately left to propagate to the error boundary. A backend outage must not be reported as "this request does not exist" — that distinction was established in fix: stop every /request/<id> URL returning HTTP 500 #116 and is preserved here.
• The two dependent queries (payments, SRF deployments) stay client-side: they hang off a payment reference derived from the request, they are the polling surface via refetchInterval, and keeping them there guarantees neither can affect the HTTP status or block the request's own content.
• One deliberate behaviour change: the page no longer blocks on a full-page skeleton while payments load. The four payments-derived cells — Status, Balance, Modified, and the payments table — render their own inline loading state. Without that they would briefly display wrong values (Balance: 0, Status taken from the last transaction instead of "Paid") before the query lands. Everything else renders immediately from the server.

Verification

npm run check ✅, npm run build ✅, tsc --noEmit clean, zero SSR errors in the server log, and against a local stand-in backend:

Check	Result
Request fields in served HTML	✅ present (were absent)
Missing request → noindex	✅
Valid request → not noindexed	✅
Missing request → 404 status	❌ 200 — framework limit, documented above

[rodrigopavezi]

• feat: server-render the request page so crawlers get the request #118 👈 (View in Graphite)
• fix: one dead subgraph no longer wipes out all payment data #117
• 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 request page now renders request data on the server while retaining browser-dependent and polling behavior in a client component.

• Adds request-specific metadata and noindex directives for missing requests.
• Deduplicates metadata and page lookups within a render pass.
• Loads the JSON editor client-side to avoid its render-time DOM access.
• Shows inline loading states while payment-derived data loads.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/app/request/[id]/page.tsx	Converts the route to an async server component, adds metadata generation, and shares the request lookup through React cache.
src/app/request/[id]/request-details.tsx	Preserves interactive request details in a client component, keeps dependent queries client-side, and isolates the DOM-dependent JSON editor from SSR.

Sequence Diagram

sequenceDiagram
    participant C as Crawler or Browser
    participant P as Request Page
    participant F as fetchRequest
    participant D as RequestDetails
    C->>P: GET /request/:id
    P->>F: getRequest(id)
    F-->>P: Channel
    P->>D: Render id and Channel
    D-->>C: Server-rendered request HTML
    Note over D,C: Payment and SRF queries continue client-side

Loading

_{Reviews (4): Last reviewed commit: "feat: server-render the request page so ..." | Re-trigger Greptile}

[rodrigopavezi]

Fixed — thanks, this was a good catch, and it was specifically this PR that made it severe.

fetchRequest sent one document covering both the storage and storage_sepolia remotes. Hasura nulls the whole document when either errors, so moving that call onto the server render meant a sepolia hiccup took down a perfectly good mainnet request. The two remotes are now queried independently via Promise.allSettled.

The fix landed one PR down, in #117 (cbe483e), since it belongs with the other query-layer resilience work rather than above it — this PR inherits it.

The part worth reviewing is what null is now allowed to mean, because this PR gave it teeth: null drives notFound() + robots: noindex.

Case	Result
Either remote returns the channel	return it, even if the other failed
Both answered, neither has it	null — a genuine not-found
Not found, but a remote failed	throw
Both failed	throw

The third row is the one that matters: "absent" and "unavailable" are indistinguishable there, and returning null would tell a crawler a possibly-live request is gone and noindex a real page. Throwing sends it to the error boundary, preserving the invariant from #116 that a backend failure is never reported as "not found". The error names the failed remotes.

Note the same pattern still exists in queries/transactions.ts and address-transactions.ts — combined storage documents. Left as follow-up; channel.ts was the urgent one because it is the only one on the SSR path.

[bassgeta]

Yup, a nice refactor on top of solving the problem 💯

[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:15 PM UTC: Graphite rebased this pull request as part of a merge.
• Jul 29, 2:16 PM UTC: @rodrigopavezi merged this pull request with Graphite.