Debugging Notes: When Your Auth Guard Silently Does Nothing

Chi Lennon — Fri, 17 Jul 2026 10:11:21 +0000

Straightforward gatekeeper logic: check the path, check the session, redirect if there's no user. But nothing was happening — unauthenticated requests sailed right into the dashboard.
The debugging process

Re-read the logic first, not the plumbing. Before touching imports or config, I re-checked the actual conditions, was isDashboardPage matching correctly, was session?.user the right check. Logic held up. So the bug wasn't in what the code did, it was in whether the code ran at all. That reframed the problem. If the logic is sound but has zero effect, the function likely isn't being invoked. That points away from application logic and toward file location/convention.
Checked where the file actually lived. proxy.ts was sitting inside lib/, not at the project root. Found the actual constraint. In Next.js 16, middleware.ts was renamed to proxy.ts, and it has to live at the project root (or inside src/, next to app) to be picked up as the framework's request-interception layer. Nested inside lib/, Next.js never registers it, it's just an unused file that happens to export a function.

Fix: moved proxy.ts to the root. Immediately started intercepting requests as expected.

Why this matters, not just as a bug fix
This isn't a cosmetic rename. proxy.ts runs before any route or page renders, before your dashboard, your API routes, even static assets get served. It's the one place in a Next.js app where you can stop a request before it costs you anything downstream: no wasted render, no wasted DB call, no exposure of protected content.
For a real product, that's the difference between:

A page that looks protected (e.g. a client-side check that flashes the dashboard for a frame before redirecting), and
A boundary that's actually enforced at the network edge, where an unauthenticated request never reaches protected logic at all.

That's the business case in one line: gatekeeping at the proxy layer isn't just about UX polish, it's what keeps unauthorized users from ever touching paid features, private data, or admin routes, regardless of what a client bypasses.
Takeaway for the post: when a function "does nothing" despite correct logic, don't just review the code, review whether the framework is even calling it. File location and naming conventions are invisible failure points that produce no error message, just silence.

Difficulty setting up MongoDB Schema

Chi Lennon — Thu, 16 Jul 2026 18:58:29 +0000

A debugging story: when your database "isn't connected"... except it is.

Building a job application tracker with Next.js + MongoDB + Mongoose, and I hit a bug that taught me more than any tutorial could.

The symptom: I'd defined my Mongoose schemas (Board, Column, JobApplication), wired up the logic to create them on user signup, and checked MongoDB Atlas... nothing. Empty. No collections, no documents. My first thought: "Is my database even connected?"

Step 1 — Prove the connection itself.
Instead of guessing, I wrote a standalone test script that connected directly, listed existing collections, and wrote a throwaway document. If that worked, the problem wasn't my URI or my cluster — it was somewhere in my app logic. It worked. Connection confirmed. So the bug was in my code, not MongoDB.

Step 2 — Chase it down layer by layer.
Turned out there wasn't just one bug — there were several, stacked on top of each other: A missing await on a findOne() call meant my "check if board exists" logic always evaluated as true (a Query object is truthy even before it resolves), so my creation logic silently never ran. My test script wasn't reading my env variables — because my file was named .env.local, and plain dotenv only looks for .env by default. I'd copy-pasted my Mongoose model registration pattern across three schema files, but didn't update the registry key each time — so Column.ts and JobApplication.ts were checking mongoose.models.Board instead of their own names. One typo like that silently corrupts your entire model registry. A singular/plural mismatch ("JobApplication" vs "JobApplications") between the check and the registration line meant the model check and the actual registration were never talking about the same thing.

Step 3 — Fix, then verify against reality, not assumptions.
After fixing the model registration and confirming my databaseHooks in Better Auth was correctly wired to run initializeUserBoard() on every new signup, I still didn't trust it — so I created a brand new test user through the actual frontend, not just my test script, and refreshed Atlas. That's when I finally saw it: boards, columns, and jobapplications collections, populated exactly as expected. The real lesson: none of these bugs threw loud errors. They failed silently — a wrong boolean, a missing file lookup, a mismatched string. As a beginner in backend work, this was the first time I really understood that "nothing is happening" is a symptom you have to investigate methodically, not a dead end. Isolate the layer, test it in isolation, then move to the next layer.

Small typos in "glue code" are often the real culprits — not the big, scary parts you're afraid of as a beginner.

Please if you have any questions, I will try my best to answer. Thank you 😊

buildinpublic #webdev #nextjs #mongodb #typescript #100DaysOfCode

DEV Community: Chi Lennon

Debugging Notes: When Your Auth Guard Silently Does Nothing

Difficulty setting up MongoDB Schema

buildinpublic #webdev #nextjs #mongodb #typescript #100DaysOfCode