The Moderation System That Was Running Perfectly — On Nobody

A solo founder discovered that their social platform's moderation system was running but not actually screening any content because a silent fallback in the authentication code caused all sessions to be treated as anonymous. The bug was caught not by any error or crash, but by a deliberate probe of the running system that revealed the identity attribute was never attached to broadcast sessions. The fix involved removing the fallback and making the system fail loudly when identity cannot be established.

This is a submission for DEV's Summer Bug Smash: Smash Stories https://dev.to/bugsmash powered by Sentry https://sentry.io/ . 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. 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. Tracing it backwards through the running system: Authorization: Bearer header. The session token existed in the app — it just never got attached to this particular request. js const broadcaster = verifiedUser || 'anonymous'; 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. Three parts, matching the three failures: Authorization: Bearer <token And then the part I care about most — the fix behind the fix: 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. 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 https://dev.to/candornetwork/how-we-made-moderation-architecturally-impossible-to-skip-7lo . 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.