A Tale of Two Bugs

by Drykath
Posted on 5 days, 7 hours ago


For starters, just a quick reminder that:

  • Dealers applications close soon! Go apply if you want to be a vendor in 2026 and you haven't yet. You have through Friday, August 1st, so just a little less than a week left!

  • Programming submissions open soon! We're aiming to have the form ready and available by August 1st, so start thinking about what you'd want to see at MCFC next year.

  • Registration for MCFC 2026 is now available. Registration is your entry ticket so get signed up to attend MCFC 2026!

There's even more happening behind the scenes, of course. (The hotel process has sooo many I's to dot and T's to cross. And Artist Alley, which many of you have asked about, will have information soon.) We'll tell you about all those things as soon as we can.

Would some technical nerdery tide you over in the mean time? If so, stick around.

Registration Hiccups

Reg officially opened on Monday, July 21st at 12:00:00 PM EDT. Technically maybe a few minutes before that. Several of you jumped in trying to get those sweet, sweet low badge numbers.

We quickly started seeing elevated error rates, telling us something was wrong. Even worse, it looked like the problem was between the bit of code that finalizes the payment and the bit of code that finalizes the write to the database.

While struggling through some pretty awful hotel internet, unfortunately slowing things down, we disabled registration while investigating the problem. The error reports contained several messages that look like:

ValueError: '2600::, 2600::' does not appear to be an IPv4 or IPv6 address

(Not the real addresses, obviously.) That's technically true: there's two addresses in there. So it failed validation when trying to write it to a database field that's designed to store a single address, which bubbled up into the dreaded "Internal Server Error" that a few of you saw.

After the 2025 convention cycle finished, we went through the usual technology refresh. Servers were rebuilt, stacks were upgraded. This time we put Cloudflare in the mix to get an additional layer of that nice web app firewall functionality to help keep your data safe. That additional layer sticks an additional address onto the header we were using to grab the client IP, and boom. 119 tests in the suite, but getting handed a second IP address wasn't one of them.

That led to the bigger question: Why on Earth are we storing IP addresses in the registration data? We've never needed it, and if we don't need it we'd rather not have it in the first place. So we shunted that little bit of code, tested, and then got registration opened back up. That field has since been dropped entirely. And as punishment for that bug, I took it upon myself to go into the payment gateway and manually reverse all of the transactions that never made it in.

Timeline of events:
12:00 PM - Registration officially opens
12:12 PM - Reg temporarily closed while investigation proceeds
12:24 PM - Hotfix implemented to disable IP address storage, reg re-opened
12:38 PM - All transactions prior to 12:12 PM reversed

Sign-in Hiccups

The other thing that came out of the opening of registration is that there was a problem in the log-in process. Having an account or being signed in to the site isn't required to register by any means. But some people like to use that to pre-fill fields or to keep track of whether or not they've registered yet. I totally get it.

As mentioned above we ran through a technology refresh after MCFC 2025 ended. A piece of the updated platform now treats "text == text" as a case sensitive comparison, whereas before the locale treated it as case insensitive. We generally take that into account in all the places where it matters, but much of the login process we'd been offloading to the platform to take care of. Turns out that's not as careful.

Long story short, where you could once log in as "username" or "Username" or such all equally well, suddenly only the lowercase form "username" would work. If you had "Username" stored in your password manager, it wouldn't let you log in. Even more frustrating, it would let you run through a password reset, and then fail to log in once it's done.

We've now overridden that login process, and make sure to tell it to use an "__iexact" username look-up, so you're free to log in as you want. And now there's 121 tests in the suite.

If you like having your registration linked to your account, make sure you're logged in then bring up the confirmation link you received after registering. There will be a button to link it on the confirmation page there.

This Is Interesting!

Is it? Well, if you've made it this far, you're probably our kind of people!

Consider joining staff and help out with this kind of stuff! There's a lot happening behind the scenes in other areas, too. It can be challenging at times, but it's a lot of fun seeing what we can do when we all come together!