White screen after releases (for some people)

robertschlackman · June 10, 2026, 2:03pm

I’ve had this nagging issue on my site for many years. I just upgraded to the latest release with rspack, and after releasing it happened to me. A handful of people will get a white screen when they go to the site. I cleared the Cloudflare cache and deleted my browser data, and the site came back. It’s impossible to duplicate consistently, so I’ve never been able to track the issue down. Has anyone else seen or known about this issue?

We are running our site in Docker containers in AWS Fargate.

xet7 · June 11, 2026, 8:35pm

@robertschlackman

I currently use Meteor 3.5-rc.1 at WeKan https://wekan.fi

I use CloudFlare Developer mode that bypasses all cache. I also have cache related headers etc. I currently use Oplog sockjs, at bare metal Ubuntu 26.04 server at Hetzner, 64 GB RAM, 2x1GB NVME RAID. My Meteor 3 WeKan Multitenancy config is fully documented here:

I use rebuild-wekan.sh to build WeKan and run all tests:

github.com

wekan/wekan/blob/main/rebuild-wekan.sh

#!/bin/bash

echo "Recommended for development: Newest Debian or Ubuntu amd64 based distro, directly to SSD disk or dual boot, not VM. Works fast."
echo "Note1: If you use other locale than en_US.UTF-8 , you need to additionally install en_US.UTF-8"
echo "       with 'sudo dpkg-reconfigure locales' , so that MongoDB works correctly."
echo "       You can still use any other locale as your main locale."
echo "Note2: Console output is also logged to ../wekan-log.txt"

function pause(){
	read -p "$*"
}

function is_dev_server_running(){
	if command -v pgrep >/dev/null 2>&1; then
		pgrep -af 'meteor run --port 3000' | grep -v 'meteor test' | grep -q '.'
		return $?
	fi
	return 1
}

This file has been truncated. show original

I use release-all.sh to change version number, then GitHub Actions builds for all platforms:

github.com

wekan/wekan/blob/main/releases/release-all.sh

#!/bin/bash

# WeKan REMOTE release script — pushes your CHANGELOG.md edit and triggers the
# GitHub Actions release workflow, which does EVERYTHING else remotely.
#
# For a fully LOCAL release (build on this machine), use ./releases/release.sh.
# This script (release-all.sh) is the REMOTE path: nothing is built, bumped or
# published on your machine — GitHub Actions does it all, in parallel.
#
# Usage:
#   1. Add the new release section to CHANGELOG.md (e.g. "# v9.36 2026-06-10").
#   2. Run:
#        ./releases/release-all.sh                 # versions read from CHANGELOG.md
#      or override explicitly:
#        ./releases/release-all.sh 9.35 9.36       # PREVIOUS NEW
#
# What this script does locally (the only local steps):
#   1. Determines PREVIOUS and NEW version (from CHANGELOG.md, or from args).
#   2. Commits and pushes pending changes (your CHANGELOG.md edit) to main so the
#      workflow can read them.

This file has been truncated. show original

For those GitHub Actions, I have created GitHub Secrets with this script:

github.com

wekan/wekan/blob/main/releases/create-github-secrets.sh

#!/bin/bash
#
# Interactive helper to create the GitHub Actions secrets required by
# .github/workflows/release-all.yml. It walks you through creating ALL or ONE of
# the secrets, optionally sets them in GitHub via the gh CLI, and saves the
# results to ../wekan-github-secrets-YYYY-MM-DD_HH-MM-SS.txt
#
# Usage:
#   ./releases/create-github-secrets.sh
#
# ─────────────────────────────────────────────────────────────────────────────
# REQUIRED GITHUB SECRETS (used by .github/workflows/release-all.yml)
# ─────────────────────────────────────────────────────────────────────────────
# Add all of the secrets below in the GitHub repo at:
#   https://github.com/wekan/wekan/settings/secrets/actions
#   Menu path: GitHub repo -> Settings (top tab)
#                           -> Secrets and variables (left sidebar) -> Actions
#                           -> "New repository secret" (green button)
#   Set "Name" to the secret name shown below and "Secret" to the value produced
#   by its "Create the value" command, then click "Add secret".

This file has been truncated. show original

italojs · June 15, 2026, 2:22pm

Do your customers share any kind of log? maybe in the console tab

robertschlackman · June 15, 2026, 2:38pm

Nothing shows in the console and I also trap errors on the client and save them in a collection in mongo. Nothing shows up in the error log. It doesn’t work again until the user clears out the client side mini mongo.

dupontbertrand · June 15, 2026, 4:58pm

@robertschlackman I’m fairly confident I can explain this (Well, Claude can) it’s a CDN caching interaction rather than a Meteor bug, and the rspack upgrade is what made a long-dormant misconfiguration start biting.

What’s happening

Meteor serves the root HTML document without a Cache-Control header. That HTML is the entry point that references your JS/CSS bundles by their content hash (e.g. /abc123.js), and those hashes change on every deploy. The hashed assets themselves are served immutable, max-age=1y — which is correct, because their URL is unique per build.

The problem is the entry document. A text/html response with no cache header invites a CDN to apply its own heuristics, and if Cloudflare is configured to cache it (a “Cache Everything” page rule, or a Cache Rule that catches HTML), the edge keeps serving an old HTML pointing at old bundle hashes. After you deploy, the new origin no longer has those files, so:

old HTML (from the edge) → requests /<oldhash>.js → 404 → the main script never loads → white screen.

This lines up with everything you described:

“Nothing in the console / error tracker” — a <script> that 404s doesn’t throw a catchable JS exception; it fires an error event on the element that window.onerror and most error trackers don’t capture. So a silent console is expected here, not evidence against it.
“Purging Cloudflare cache fixes it” — that evicts the stale HTML at the edge, so everyone gets the new entry document.
“Clearing browser data fixes it for that user” — same fix one layer down: it drops the browser’s own heuristic copy of the header-less HTML (plus the autoupdate version Meteor persists in localStorage), forcing a fresh fetch. (Side note on “clearing minimongo”: vanilla minimongo is in-memory and can’t persist across a reload, so the artifact actually being cleared is the cached HTML/bundle + that localStorage version — same root cause, the wording just points elsewhere.)

And critically: when the entry bundle 404s, the app never boots far enough to open a DDP connection, so Meteor’s own hot-code-push/autoupdate can’t kick in to self-heal. The user is stuck until the cache expires or is cleared.

Why rspack made it worse

Pre-rspack your app shipped largely as one bundle, so a stale entry failed in exactly one way. rspack splits every import() boundary into its own content-hashed chunk, deletes the previous build’s chunks on each deploy (its clean step — no grace window where old and new coexist), and ships no retry/reload on a failed chunk load. So now there are many more independently-versioned files that can 404, and zero tolerance for a stale reference. A client running an old bundle that lazy-loads a route then hits a ChunkLoadError (the chunk hash it wants was deleted), and the route renders blank. The upgrade itself was the trigger because it was a single deploy that rotated every hash at once.

How to confirm (2 minutes)

Next time it happens, or just on a normal load:

DevTools → Network. Reload. Look for any .js/.css returning 404. If you see one, that’s it.
Click the document request for / → Response Headers. Look for cf-cache-status: HIT and whether there’s a Cache-Control. If Cloudflare is serving the HTML from cache, that’s the smoking gun.

The fix

It’s on the Cloudflare side:

Never edge-cache the HTML document. Find the “Cache Everything” page rule (or Cache Rule) and exclude text/html / your app routes from it. Cloudflare’s default already bypasses HTML — so if you’re hit by this, something is explicitly caching it.
Keep caching the hashed assets aggressively — they’re already immutable and safe.

Optional belt-and-suspenders for the rspack chunk case: add a global handler that catches ChunkLoadError / a failed dynamic import() and does a single window.location.reload().

There’s also a reasonable argument that Meteor should send Cache-Control: no-cache on the boilerplate HTML by default instead of trusting every CDN to be smart — happy to raise that with the core team if others run into this.

Let me know what the Network tab shows after a repro — if it’s a 404 on the entry bundle, the Cloudflare rule is the whole story. Cc @italojs

robertschlackman · June 15, 2026, 5:14pm

Thanks so much. This makes a lot of sense. I’ll check back when I can provide more information about this fix.