fix(deploy): retire the maintenance banner — the outage it describes is over - #234
Merged
Merged
Conversation
size-limit report 📦
|
…is over Every publish build since the wind-down has pinned VITE_MAINTENANCE_MODE='1', so instanode.dev has been telling every visitor "instanode is temporarily unavailable while we perform maintenance… we'll be back shortly" — sticky banner on all 14 public routes, plus a BLOCKING modal on /login* and /app*. That was true when the prod cluster was intentionally paused. It stopped being true when api.instanode.dev came back on Azure AKS with a real Let's Encrypt certificate. The header above the flag already carried the removal instruction; it was simply never executed once the cluster returned, so the banner outlived its outage by about two months and the site has been advertising downtime while the platform served traffic normally. Verified green against the LIVE platform before removing it — the banner is honest protection while things are broken, so it only comes down once they are not: provision → psql round-trip (create/insert/select) /cache/new → redis-cli SET/GET /storage/new → presign PUT → presign GET (real bytes back) /stacks/new → live app on a Let's Encrypt cert (issuer CN=YR2) POST /internal/set-tier → 404 (prod gate holds) GET /metrics → 401 (now token-gated) Excluded by scope: /queue/new (NATS isolation mid-fix) and Razorpay (unconfigured, out of scope for the migration). The flag is removed rather than set to '0' — MaintenanceNotice.tsx renders null when it is unset, and the component plus its vite-env declaration stay, so a genuine maintenance window is one line away. The comment now forbids re-pinning it to a build-event expression: an expression that is always true on publish is indistinguishable from "on forever", which is exactly how this shipped. Verified on the built artifact, not just the config: `npm run gate` green (87 files, 1285 passed), then served dist/ and loaded it in Chromium — the banner is absent from / and the blocking modal is absent from /login, with the sign-in form fully reachable. Grepping the bundle for the copy is NOT a valid check: the strings are module-level constants that compile in regardless, and only the inlined flag decides whether they render. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
mastermanas805
force-pushed
the
fix/retire-maintenance-banner
branch
from
August 13, 2026 05:57
5ad281e to
3c228d5
Compare
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
1 participant
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
Removes
VITE_MAINTENANCE_MODEfrom the Pages publish build.MaintenanceNotice.tsxand itsvite-env.d.tsdeclaration stay — the component rendersnullwhen the flag is unset, so a realmaintenance window is one line away.
Why
Every publish build since the wind-down pinned the flag to
'1', so instanode.dev has been showinga sticky "instanode is temporarily unavailable while we perform maintenance… we'll be back
shortly" banner on all 14 public routes, plus a blocking modal on
/login*and/app*.That was accurate while the prod cluster was intentionally paused. It stopped being accurate when
api.instanode.devreturned on Azure AKS with a real Let's Encrypt certificate. The comment blockabove the flag already documented how to turn it off; that step was never executed on resume — so
the site has spent roughly two months advertising downtime while the platform served traffic.
Found by a browser-driven UI audit, which also caught the related class of defect (a hardcoded
"All systems · operational" footer contradicting a
/statuspage reporting 0% uptime) — trackedseparately.
Verified green BEFORE removing it
The banner is honest protection while the platform is broken, so it only comes down once it isn't.
All against the live deployment:
POST /db/new→psqlPOST /cache/new→redis-cliPOST /storage/new→ presignPOST /stacks/newCN=YR2)POST /internal/set-tierGET /metricsOut of scope by decision:
/queue/new(NATS per-tenant isolation mid-fix) and Razorpay(unconfigured).
Verified on the artifact, not the config
npm run gategreen — 87 test files, 1285 passed, 3 skipped. Then serveddist/and loaded it inChromium: banner absent from
/, blocking modal absent from/login, sign-in form fully reachable.Worth recording for the next person: grepping the bundle for the copy is not a valid check.
MAINTENANCE_HEADLINE/MAINTENANCE_BODYare module-level constants that compile in regardlessof the flag — they are still present in a banner-off build. Only the inlined
import.meta.env.VITE_MAINTENANCE_MODE === '1'decides whether anything renders, so the test hasto be behavioural.
One rule added
The comment now forbids re-pinning the flag to a build-event expression.
${{ github.event_name != 'pull_request' && '1' || '0' }}is always true on publish, which is operationally identical to "onforever" while looking conditional — that is precisely how this shipped unnoticed.
🤖 Generated with Claude Code