Skip to content

Troubleshooting

Common issues and fixes encountered during local development.

Next.js HMR Loops / Full Page Reloads

Symptom: The app keeps doing full page reloads instead of HMR (hot module replacement) updates. You'll see a pattern in DevTools like:

422e8755f9b24731.webpack.hot-update.json   200
12be9a7f109e7af1.webpack.hot-update.json   404  ← triggers full reload
signin                                      200  document (from hot-reloader-pages.js)

The HMR fetches are initiated by VMxxxxx (eval'd) scripts.

Root cause: The Console Ninja VS Code extension injects scripts into the browser on every page load. Those scripts attempt to open a WebSocket connection to localhost:63960. When that server isn't reachable, the injected script keeps retrying, interfering with Next.js HMR — causing a loop where a *.webpack.hot-update.json request returns 404, which triggers a full reload, and the cycle repeats.

Fix: Disable the Console Ninja extension in VS Code and hard refresh the browser.

Tip

If you install Console Ninja to improve your debugging experience and suddenly see weird hot-reload behavior, this is likely the culprit. Disable the extension first before investigating further.

All-White Screen with __turbopack_load_page_chunks__ is not defined

Symptom: Running bun run dev shows an all-white screen with this error in the browser console:

Uncaught ReferenceError: __turbopack_load_page_chunks__ is not defined

Root cause: A Turbopack bug where its internal cache gets corrupted (related to a Rust-level CLOEXEC pipe assertion failure). This is not caused by any code changes — it's a bug in the bundler itself.

Fix:

  1. Stop the dev server
  2. Clear the Next.js cache: 
    rm -rf apps/web-commercial/.next
  3. Run bun run dev again
  4. Hard refresh the browser with Cmd+Shift+R

If it happens again after that, also clear the Turbo cache:

rm -rf node_modules/.cache .turbo apps/web-commercial/.next

Note

This only affects local development. Production and staging builds on Vercel are not impacted since they always do clean builds.

A bash guard that never fires: $$VAR expands to the PID

Symptom: A shell conditional meant to skip work when a variable is unset runs anyway — every time, on every host. Or the mirror image: a branch you expect to be skipped is always taken, and the failure shows up further downstream as a connection error rather than as a bad condition.

# looks like it guards on PRIMARY_PG_HOST; does not
if [ "$PRIMARY_PG_REPL_TYPE" == "logical" ] && [ "$$PRIMARY_PG_HOST" != "" ]; then

Root cause: $$ is the PID of the current shell, not the start of a variable reference. "$$PRIMARY_PG_HOST" expands to something like 1234PRIMARY_PG_HOST — a non-empty string, always — so != "" is unconditionally true and the guard is inert. Nothing errors, and the variable it claims to test is never read at all.

Fix: a single $.

if [ "$PRIMARY_PG_REPL_TYPE" == "logical" ] && [ "$PRIMARY_PG_HOST" != "" ]; then

Where this has bitten us: three occurrences in cred-postgres — one in scripts/postgres-post-init.sh and two in scripts/cred-postgres-entrypoint.sh, gating pg_basebackup and subscribe-pglogical.sh for a replica with no configured provider host. All three fixed 2026-08-11.

Tip

shellcheck catches this, but not where you would expect: it reports SC2193 — "The arguments to this comparison can never be equal", because "<pid>PRIMARY_PG_HOST" can never equal "". It says nothing about $$, so the message reads as a puzzling comparison warning rather than a variable bug. Verified with shellcheck 0.11.0 on exactly this pattern.

It is also invisible to a reading eye, because the line looks like normal variable interpolation. When a conditional seems to be ignored, print both forms of the variable you think you are testing before debugging anything else — using its real name, not a placeholder:

echo "wrong: [$$PRIMARY_PG_HOST]  right: [$PRIMARY_PG_HOST]"
# wrong: [12345PRIMARY_PG_HOST]  right: [cred-model-db.cred.internal]