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.
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))returnnull;
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Both
/systemsand/nodesintermittently white-screen with "Application error: a client-side exception has occurred while loading drb.cusano.net". Console (prod bundle, git_sha861ea41, 2026-08-23):and the same trace with
at N (chunks/app/systems/page-0f32ca9b12af7b66.js).React #310 is a conditional/variable hook count — a
useState/useEffectreached on some renders and not others, almost always because of an earlyreturnabove it. Both files have exactly that shape: the auth guards atapp/nodes/page.tsx:19andapp/systems/page.tsx:1188sit alongside early returns whileauthLoadingflips, andapp/systems/page.tsxis 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/Ncomponents 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.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:
/systemsand/nodesboth render clean on a fresh load of git_sha861ea41.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: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
/networkpage follows the same hooks-before-guard shape.