The Moderation System That Was Running Perfectly — On Nobody

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The setup

I'm a solo founder building a social platform where content screening is the whole point. Livestreams get transcribed in real time and fanned out to AI analyzers — extremism detection, crisis detection — and the broadcaster's identity rides along so the system knows whose stream it's screening and can act on it.

Identity flows through a JWT. Client logs in, gets a token, token accompanies the broadcast session, screening pipeline attributes everything correctly. Standard stuff. It worked in every test I ran during development.

Here's the thing about this bug: there was no symptom. No crash, no error log, no user complaint. Streams worked. Screening worked — I could see the analyzers firing. Everything looked healthy. That's what makes this one worth writing up.

The hunt

I run my project under a rule I call §0: "designed," "coded," and "verified working end-to-end" are three different statements, and only probes against the running system count as evidence. It exists because I once caught my deployed system quietly diverging from its design, one easy shortcut at a time, and I decided never again.

So during a verification pass on the broadcast path, I wasn't asking "does streaming work?" — it obviously did. I was asking a more §0 question: prove to me that a logged-in broadcaster's session carries their verified identity into the screening pipeline. Show me the actual value, from the actual running system.

The probe came back wrong. The session that should have been my authenticated test user was attributed to anonymous.

One session, maybe a fluke. I logged in again, fresh. Anonymous. Every single post-login session was anonymous.

The dig

Tracing it backwards through the running system:

1. The client wasn't sending the token. The broadcast token request went out without an Authorization: Bearer header. The session token existed in the app — it just never got attached to this particular request.
2. The server didn't mind. The token route did no server-side JWT verification of its own. No token? No problem. It fell through to a default:

const broadcaster = verifiedUser || 'anonymous';

1. And there was a third layer: even when auth did work, the client wasn't hydrating the session from storage after a page reload — so any refreshed session lost its identity anyway and fell into the same anonymous path.

Three small, defensible-looking decisions. A missing header. A convenient fallback. A skipped hydration step. Each one written with good intentions, none of them logging anything, and together they meant: after login, every session silently fell back to anonymous.

Why does that matter beyond bookkeeping? Because anonymous sessions took a different code path — one that bypassed identity-attributed screening entirely. The moderation stack was deployed, healthy, and fully operational. It just wasn't in the loop for the sessions that mattered. A safety system in the "on" position, wired to nothing.

The fix

Three parts, matching the three failures:

1. Server-side JWT verification on the token route. The server now verifies the token itself, cryptographically, before issuing anything. Client claims are not trusted.
2. Client sends Authorization: Bearer <token> on the token request. The obvious missing piece, made explicit.
3. localStorage hydration on load, so a refreshed session recovers its verified identity instead of silently downgrading.

And then the part I care about most — the fix behind the fix:

1. The fallback died. Not just this one — the pattern. My platform now runs a fail-loud rule: no silent defaults on anything security- or safety-relevant, anywhere. A missing secret at boot is process.exit(1), not || 'change-me'. A verification failure is a refusal, not a downgrade to a friendlier identity. If the system can't establish who you are, it doesn't guess — it stops, loudly.

Verified after the fix the same way it was caught: probes against the live system, logged with dates. Authenticated session in, verified identity out, screening attributed correctly, on the running box — not in my head, not in the code review.

What this bug taught me

Silent fallbacks are camouflage. || 'anonymous' looks like defensive programming. It's actually a machine for converting failures into fake success. The system didn't degrade visibly — it degraded into something that looked identical to working.

"It works" and "I verified it works" are different sentences. Every test I ran during development passed, because development tests exercise the paths you thought of. The bug lived in the gap between the design in my head and the system on the box, and only a probe of the running system — asking it to prove its own behavior — could see into that gap.

The worst bugs don't throw. Sentry-style error monitoring is essential, but this class of bug never generates an error to monitor — every code path "succeeded." The only detection mechanism is refusing to let failure be expressible as success: fail loud, fail closed on the paths that matter, and make silence itself impossible.

This bug ultimately changed my platform's architecture — I rebuilt the write path so that this entire class of bypass can't exist, which I wrote up separately in How We Made Moderation Architecturally Impossible to Skip. But the architecture came second. First came the humbling: my safety system spent its early life running perfectly, on nobody, and nothing anywhere was ever going to tell me.

Now something does. Loudly.