The Great "Can't Log In" Saga
If you tried to log in to ChatStats.live over the past week or so, only to be met with an error message or, worse, for nothing to happen at all. rest assured, it wasn't just you! While working behind the scenes to move the site to our new database, I unintentionally broke logins for everyone, including myself. Oops. 😅 Let’s take a deep dive into what happened, why it happened, and what I learned along the way. This post gets a little technical, so buckle up.
What Happened?
I'm currently in the process of migrating everything over to a shiny new Supabase database. The goal is to improve reliability, security, and retire a lot of the clunky, makeshift code from the old system. In the course of hooking things up, I pushed a change that, unfortunately, completely broke the Twitch login flow across the entire site. This change was only meant to run in the background and shouldn’t have affected anything user-facing but as you might guess, things didn’t go as planned.
Here’s the Kicker
This problematic change was actually deployed on January 17th. So, the broken code was live for some time before I noticed the issue and rolled back the change. It’s always the little “background” changes that slip by you.
What Did Users Experience?
Here's what the average user might have seen:
- Trying to log in with Twitch sometimes did nothing, or a vague error appeared.
- Logins worked for a short period, and would inexplicably stop again.
- Some users were forcibly logged out and couldn't get back in at all, no matter what they tried.
As you can imagine, this was very confusing and frustrating for both users and myself. There was genuinely no clear error feedback, and it took some digging to track down what was going on.
Is It Fixed Now?
I believe everything is working normally again. If you’re still having trouble logging in, please try a hard refresh of the page (CTRL + F5 on most browsers) to clear any cached files. If issues persist, feel free to get in touch.
The Technical Breakdown What Actually Happened?
So, what went wrong under the hood? While making the database changes, I updated the login flow by adjusting which users could sign up or log in. This was a small change meant to finally allow both Twitch Partners and Affiliates to access ChatStats.live. It felt like the best time to do it, given the new database, and had been on my “to-do” list for a while.
Here’s the code snippet at the core of the mess:
// Check if user is a partner or affiliate (allow both)
const broadcasterType = await this.checkBroadcasterType(user.id);
if (broadcasterType !== 'partner' && broadcasterType !== 'affiliate') {
this.logout();
alert("Sorry, ChatStats.live is currently only available for Twitch Partners and Affiliates...");
return null;
}
At first glance, it looks like a simple check to see if someone is a Partner or Affiliate. But, it turns out, the logic is more subtle than that.
if (broadcasterType !== 'partner' && broadcasterType !== 'affiliate')
This condition will only be true if broadcasterType is neither 'partner' nor 'affiliate' which, in practice, should only catch the empty-string (""), meaning a regular user. However, in how Twitch’s API returns values, it will only ever be "affiliate" or "partner" or "", and my code mistakenly assumed the check covered things the right way. In reality, the code was overcomplicating things and, due to some quirks, ended up blocking even valid users. A user can't be both an affiliate and a partner at the same time, but my logic was overly strict.
Twitch intends for broadcasterType to always be exactly one of three possible strings. My check was trying to validate both at once, instead of simply seeing if it was not empty.
This check could have, and should have, been:
if (broadcasterType === '') {
This version is much clearer and easier to understand. It strictly checks if the user is neither an Affiliate nor a Partner (just a regular broadcaster), and prevents them from logging in. It’s also less likely to break due to changes in API behavior or unnoticed edge cases.
Another issue was using a loose equality operator in the original check, which can lead to unexpected results. The simpler approach is more robust and readable.
When the (incorrect) login request was sent to the database, the system responded with an error. It would claim that the user was not a Partner or Affiliate even for valid users! That’s why nobody (including myself) could log in.
This was my mistake. Migrations and refactors can be tricky, and in this case, I missed an edge case that didn’t show up in local testing especially since I was already logged in, so the error slipped by for a while.
PS: Why the Database Migration?
This migration is a major step toward scaling up as ChatStats.live grows, letting us support more users more reliably and securely. The move also helps us leave behind the limitations of the old database, and, honestly, it’s a great learning experience for me as well.
Thanks, as always, for using ChatStats.live and being patient through growing pains like this. I promise to be more careful in the future!