feat(tips): gate the chain switcher on a runtime TIPS_CHAINS allowlist - #78
Open
montycheese wants to merge 1 commit into
Open
feat(tips): gate the chain switcher on a runtime TIPS_CHAINS allowlist#78montycheese wants to merge 1 commit into
montycheese wants to merge 1 commit into
Conversation
The internal deployment serves different chains per environment: production reaches the mainnet and sepolia bundle-history buckets, development reaches zeronet. Until now the switcher offered all three everywhere, so production showed a Zeronet tab it has no data for. NEXT_PUBLIC_DEPLOY_TARGET cannot express this. It is inlined at build time, and the internal target builds one image that is promoted from development to production — the two environments differ only in runtime env. So this reads a new TIPS_CHAINS allowlist per request instead: - app/tips/enabledChains.ts resolves it server-side (server-only: TIPS_CHAINS is not a NEXT_PUBLIC_ var). - TipsChainsProvider carries the list into the client tree, which cannot read the env itself; the section layout resolves it once per request. - ChainToggle renders only the enabled chains, and hides itself entirely when there is only one. - useTipsChain clamps `?chain=` to the enabled list, so a shared zeronet link opened against production reads as mainnet rather than erroring. - The TIPS API routes 404 a chain this deployment does not serve, rather than falling through to per-chain config that is unset here — which would read the default bucket and either 500 or answer from the wrong source. Unset means every known chain, so local dev and any deployment that does not set it behave exactly as before.
Collaborator
🟡 Heimdall Review Status
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The TIPS chain switcher offered Base Mainnet, Base Sepolia, and Zeronet in every
deployment. The internal deployment does not serve the same chains in every
environment — production reaches the mainnet and sepolia bundle-history buckets,
development reaches zeronet — so production showed a Zeronet tab with no data
behind it.
This gates the switcher (and the TIPS API) on a
TIPS_CHAINSallowlist:TIPS_CHAINSmainnet,sepoliamainnet,sepolia,zeronetWhy it is runtime config, not a build flag
NEXT_PUBLIC_DEPLOY_TARGETcan't express this. It is inlined into the bundle atbuild time, and the internal target builds one image that is promoted from
development to production — the two environments differ only in the runtime env
the Helm chart sets. A build-time flag would have to be the same in both. The
chart already varies the per-chain
TIPS_*vars this way;TIPS_CHAINSjoinsthem.
How
app/tips/enabledChains.ts— resolves the allowlist server-side. Server-only:TIPS_CHAINSis deliberately not aNEXT_PUBLIC_var.app/tips/components/TipsChainsProvider.tsx— carries the list into the clienttree, which can't read the env itself. The section layout resolves it once per
request.
ChainTogglerenders only the enabled chains, and hides itself when there isonly one (a single tab is a label, not a control).
useTipsChainclamps?chain=to the enabled list, so a shared zeronet linkopened against production reads as mainnet instead of erroring.
back to the default chain would answer under the wrong chain's name, and
letting it through would hit per-chain config that is unset here — reading the
default bucket and either 500ing or, worse, succeeding against the wrong
source.
deployment that doesn't set it. A typo'd value is treated as unset rather than
emptying the section.
Testing
app/tips/chains.test.tscovers allowlist parsing (whitespace, case,duplicates, unknown names, empty) and the clamping fallbacks, including the
production case of a zeronet link resolving to mainnet.
npm run typecheck— cleannpx vitest run— 19 files, 146 tests passnpm run build:internalandnpm run build— both exit 0npm run docs:check— all currentVerified in the browser against a dev server, three configurations:
/api/tips/blocks?chain=zeronetTIPS_CHAINS=mainnet,sepolia404 {"error":"Not found"}TIPS_CHAINS=mainnet,sepolia,zeronetWith the production allowlist,
/tips?chain=zeronetrenders with Base Mainnetselected and no Zeronet tab.
Follow-up
This has no effect until the internal chart sets
TIPS_CHAINSper environment;that is a separate PR in the internal deploy repo, alongside the image bump.