React error #310 white-screens /systems and /nodes #32

New Issue

2026-08-23T02:14:09-04:00

logan commented

2026-08-23 02:14:09 -04:00

Both /systems and /nodes intermittently white-screen with "Application error: a client-side exception has occurred while loading drb.cusano.net". Console (prod bundle, git_sha 861ea41, 2026-08-23):

Error: Minified React error #310  (Rendered more hooks than during the previous render)
  at Object.useState
  at u  (chunks/app/nodes/page-a668c810e856238f.js)

and the same trace with at N (chunks/app/systems/page-0f32ca9b12af7b66.js).

React #310 is a conditional/variable hook count — a useState/useEffect reached on some renders and not others, almost always because of an early return above it. Both files have exactly that shape: the auth guards at app/nodes/page.tsx:19 and app/systems/page.tsx:1188 sit alongside early returns while authLoading flips, and app/systems/page.tsx is 1,100+ lines with several nested components.

Not reliably reproducible on demand — it survived across two sessions (11:23 PM and 2:07 AM local) and a subsequent reload of the same URL rendered fine, so it is a render-order race, not a hard break. Once thrown it takes the whole page down, no error boundary catches it.

Fix: find the hook that sits below a conditional return in the u/N components in those two files and hoist every hook above every early return. A dev-mode (non-minified) reproduction will name the component outright. An error boundary around the route group would keep a recurrence from blanking the page.

Both `/systems` and `/nodes` intermittently white-screen with **"Application error: a client-side exception has occurred while loading drb.cusano.net"**. Console (prod bundle, git_sha 861ea41, 2026-08-23): ``` Error: Minified React error #310 (Rendered more hooks than during the previous render) at Object.useState at u (chunks/app/nodes/page-a668c810e856238f.js) ``` and the same trace with `at N (chunks/app/systems/page-0f32ca9b12af7b66.js)`. React #310 is a conditional/variable hook count — a `useState`/`useEffect` reached on some renders and not others, almost always because of an early `return` above it. Both files have exactly that shape: the auth guards at `app/nodes/page.tsx:19` and `app/systems/page.tsx:1188` sit alongside early returns while `authLoading` flips, and `app/systems/page.tsx` is 1,100+ lines with several nested components. Not reliably reproducible on demand — it survived across two sessions (11:23 PM and 2:07 AM local) and a subsequent reload of the same URL rendered fine, so it is a render-order race, not a hard break. Once thrown it takes the whole page down, no error boundary catches it. Fix: find the hook that sits below a conditional return in the `u`/`N` components in those two files and hoist every hook above every early return. A dev-mode (non-minified) reproduction will name the component outright. An error boundary around the route group would keep a recurrence from blanking the page.

logan commented

2026-08-23 02:21:49 -04:00

Closing — I filed this off stale evidence. The #310 traces I read out of the Chrome console were console history from a tab loaded at 23:23 local on 2026-08-18, two minutes before the fix landed, plus one replay of that same frozen tab. The current bundle does not reproduce it: /systems and /nodes both render clean on a fresh load of git_sha 861ea41.

d041c86 ("Run every hook before the admin guard on /nodes and /systems", 2026-08-18 23:25) already fixed it, and both files now carry the explanatory comment:

// Every hook must run before this guard. React tracks hooks by call order,
// so returning early on the first render and then reaching a useState on the
// next one is error #310 ...
if (authLoading || (!isAdmin && !isOperator)) return null;

It only looked live because the deploy failures in #21 meant prod served 08-18 code until 08-20, so the crashing bundle was in the field for two days after the fix was committed.

No action needed. The new /network page follows the same hooks-before-guard shape.

Closing — I filed this off stale evidence. The #310 traces I read out of the Chrome console were console *history* from a tab loaded at 23:23 local on 2026-08-18, two minutes before the fix landed, plus one replay of that same frozen tab. The current bundle does not reproduce it: `/systems` and `/nodes` both render clean on a fresh load of git_sha 861ea41. `d041c86` ("Run every hook before the admin guard on /nodes and /systems", 2026-08-18 23:25) already fixed it, and both files now carry the explanatory comment: ```ts // Every hook must run before this guard. React tracks hooks by call order, // so returning early on the first render and then reaching a useState on the // next one is error #310 ... if (authLoading || (!isAdmin && !isOperator)) return null; ``` It only *looked* live because the deploy failures in #21 meant prod served 08-18 code until 08-20, so the crashing bundle was in the field for two days after the fix was committed. No action needed. The new `/network` page follows the same hooks-before-guard shape.

logan closed this issue

2026-08-23 02:21:50 -04:00

logan added the area/frontend

type

bug

labels 2026-10-05 02:04:24 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: logan/server-26#32