The comment I left in the code said // race fix is shipped but UNVERIFIED. I’ve committed a lot of speculative things, but that one felt different. Most TODO comments assume the code is probably fine. UNVERIFIED means you’ve tested enough to believe the fix is right, you just haven’t closed the loop.
That was 11:43 PM. The Supabase free tier gives you two magic-link emails per hour. I’d used both, one to confirm sign-in worked and one to test board ownership. The rate limit was going to reset in 45 minutes.
I went to bed.
The auto-claim flow is the part I couldn’t test. After you sign in for the first time, the system is supposed to adopt all the boards you created anonymously and back-fill ownership. It’s the thing that makes auth feel seamless rather than punishing. And it was broken by a race condition: SIGNED_IN fires before the Svelte component that registers the claim handler has mounted. So the handler wasn’t there when the event fired. The boards never got adopted.
My fix handles INITIAL_SESSION instead of waiting for SIGNED_IN, then does an immediate getSession() check on mount as a fallback. Two separate places to catch the session: the first handles the case where the event fires before mount, the second catches everything the first misses.
I wrote that down, committed, and closed the laptop.
This morning I came back. Created a new board as an anonymous user, added three cards, closed the tab. Opened an incognito window, navigated to Kudos, signed in via magic link. Watched the URL clear the ?code= parameter and resolve to the dashboard.
The boards were there. All three. “Owned by you.”
Here’s the thing though: I already knew it was going to work. Not because I’m that good at writing Svelte, but because I’d traced the execution path twice before committing. I knew where supabase-js detected the ?code= parameter. I knew what INITIAL_SESSION represented versus SIGNED_IN. The fix was logically correct. What I got from verification wasn’t new information about the code. It was confirmation that my mental model matched the actual runtime.
Those two things are close but not the same. Logic is reasoning about what should happen. Verification is proof that reality agrees.
I’d been treating “logically sound” as “works until proven otherwise” for years, especially at the end of long sessions when I wanted to be done. You trace the code, you convince yourself, you ship it and call it good enough. For a lot of cases that works. But for anything that depends on event timing, component lifecycle, or external services with hard rate limits, “good enough” is where bugs live.
Go to bed. Come back. Watch it run.
If the version of you at midnight is writing UNVERIFIED in a code comment, that’s the right call. The version of you the next morning is the one who should be verifying it.