fix(idl): dedupe Anchor IDL fetches during Suspense retries

[rogaldh]

Description

useIdlFromAnchorProgramSeed re-enters its fetch on every Suspense retry for known clusters (Mainnet/Testnet/Devnet/Simd296) because the API-branch never wrote the in-flight promise into cachedAnchorProgramPromises. Each render → a fresh /api/anchor request → a flood of duplicate calls. The symptom is most visible on legacy BPF-loader-owned programs (Token Program, etc.) where the address-layout <AccountDataTab> calls useAnchorProgram(account.owner) and account.owner is BPFLoader2111… — visiting /address/TokenkegQ.../security on a local explorer would issue tens of identical /api/anchor?programAddress=BPFLoader2… requests before the first response resolved.

Both branches now call a shared recordInFlight(key, promise) before throw promise;, so Suspense retries short-circuit on cacheEntry.__type === 'promise' instead of refiring the request.

Type of change

• Bug fix

Screenshots

N/A — runtime fix, no UI change.

Testing

Added app/entities/idl/model/__tests__/use-idl-from-anchor-program-seed.test.ts with two regression tests:

• API-branch (Cluster.MainnetBeta): stubs global.fetch, asserts the second invocation throws the same promise and fetch is called once.
• Custom-branch: spies on Program.fetchIdl, asserts the same dedup invariant.

Verified the suite fails against pre-fix code and passes after the fix:

pnpm vitest --project specs run app/entities/idl/model/__tests__/use-idl-from-anchor-program-seed.test.ts

Related Issues

N/A

Checklist

• My code follows the project's style guidelines
• I have added tests that prove my fix/feature works
• All tests pass locally and in CI
• I have run build:info script to update build information
• CI/CD checks pass

[vercel]

@rogaldh is attempting to deploy a commit to the Solana Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
explorer	Ready	Preview, Comment	May 27, 2026 9:31pm

[rogaldh]

@askov please take a look

[greptile-apps]

Greptile Summary

This PR fixes a Suspense retry storm where the API branch of useIdlFromAnchorProgramSeed never wrote the in-flight promise into cachedAnchorProgramPromises, causing a fresh /api/anchor fetch on every Suspense retry. The fix introduces a shared recordInFlight helper called in both branches before throw promise, so retries short-circuit on the cached promise.

• Core fix (use-idl-from-anchor-program-seed.ts): recordInFlight(key, promise) is now called in the API (fetch) branch before throw promise, matching the existing behaviour of the Custom/Program.fetchIdl branch.
• Tests (use-idl-from-anchor-program-seed.test.ts): Two new regression tests confirm that both branches throw the same promise on the second invocation and only invoke the underlying fetch once.

Confidence Score: 5/5

Safe to merge — the change is minimal and well-targeted, fixing a concrete duplicate-fetch regression with direct regression tests.

The fix is a two-line addition to an already correct pattern (the custom branch already did this). The new recordInFlight helper is called synchronously before throw promise, so there is no window for a re-render to slip through. The new tests confirm both branches deduplicate correctly and would have caught the original bug.

No files require special attention.

Important Files Changed

Filename	Overview
app/entities/idl/model/use-idl-from-anchor-program-seed.ts	Adds recordInFlight helper and calls it in the API branch (was previously missing), fixing the duplicate-fetch-on-Suspense-retry bug; also exports resetCacheForTesting for test hygiene.
app/entities/idl/model/tests/use-idl-from-anchor-program-seed.test.ts	New regression tests verifying both branches (API/fetch and Custom/Program.fetchIdl) deduplicate in-flight promises correctly; uses resetCacheForTesting in afterEach.

_{Reviews (2): Last reviewed commit: "fix cache issue" | Re-trigger Greptile}

[askov]

@askov please take a look

Good, but conflicts with #994 (solves the same problems too)

[rogaldh]

@askov please take a look

Good, but conflicts with #994 (solves the same problems too)

Will we merge this first to mitigate the issue and #994 after, as it has greater scope?

[askov]

@askov please take a look

Good, but conflicts with #994 (solves the same problems too)

Will we merge this first to mitigate the issue and #994 after, as it has greater scope?

ok