This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Everything Stops

You know what happens when there's a bug in authentication?

Nothing.

Seriously... absolutely nothing.

Not because nothing is broken, but because users simply can't get past the front door. They can't log in, which means they can't access the application, complete a booking, view their information, or do whatever they came there to do in the first place.

Normally that's annoying.

But what if the application isn't just another website?

At the time, I was part of the authentication engineering team responsible for rolling out Multi-Factor Authentication (MFA) for government service centres across the state. These weren't internal dashboards or social media apps. These were systems used every day by frontline staff helping thousands of citizens.

No login meant staff couldn't process driver's licence applications or renewals. They couldn't register births, deaths or marriages. They couldn't update identity records. During emergencies, they couldn't access systems used to support disaster relief efforts.

The application itself was perfectly healthy. The backend was running. APIs were responding. Databases were online.

But none of that mattered.

Authentication is the front door. If the front door doesn't open, it doesn't matter how well the rest of the house is built.

A Rollout We Thought Was Perfect

Because authentication is so critical, we treated the rollout with the level of care you'd expect.

We had unit tests, integration tests, end-to-end tests, security reviews and user acceptance testing. We tested happy paths, failure scenarios, edge cases and everything in between.

Everything passed.

The rollout went live.

For a while, everything looked great.

Then a few support tickets started appearing.

Some users couldn't log in.

The strange part was that it only affected a handful of people. Most users authenticated successfully, while a small group consistently received a server error.

Those are the bugs every engineer dreads.

If nobody can log in, you usually know where to start.

If only some users can't log in, every assumption suddenly becomes a possibility.

Was it their browser?

Their location?

Their account?

A feature flag?

Some weird cached session?

We checked everything.

We dug through authentication logs, replayed requests, inspected network traffic, reviewed configuration, and read the login code more times than I'd like to admit.

Everything looked correct.

Stop Looking at Logs. Watch People.

Eventually, our team decided to do something different.

Instead of staring at dashboards and log files, we visited one of the service centres and watched people use the application.

Within minutes, we noticed something.

The users clicking the Login button with their mouse authenticated successfully every single time.

The users navigating with the keyboard, pressing Tab and then Enter, consistently hit the server error.

That tiny observation immediately felt important.

As the feature lead developer for the MFA rollout, something clicked.

This wasn't random.

This wasn't infrastructure.

This wasn't the backend.

It had to be the browser.

The Smallest Bug with the Biggest Impact

The culprit?

One missing line.

e.preventDefault();

Enter fullscreen mode Exit fullscreen mode

For anyone unfamiliar with it, e.preventDefault() prevents the browser from performing its default action.

In a React Single Page Application, forgetting it during form submission means the browser performs a traditional form submission instead of letting React handle the authentication flow.

Our React application was being bypassed completely.

Instead of executing our login logic, the browser submitted the form directly to the backend.

Mouse clicks happened to work through our React event handler.

Keyboard submissions didn't.

Every automated test had passed.

Every security review had passed.

And yet government service centre staff couldn't access the systems they needed simply because one line of code was missing.

The Lesson Wasn't About e.preventDefault()

I'm proud that once I saw someone press Enter, I immediately suspected browser default behaviour and tracked the problem back to the missing e.preventDefault().

But honestly, that wasn't the biggest lesson.

The biggest lesson was about users.

We spend a lot of time talking about AI-assisted development, automated testing and improving engineering productivity.

I'm a huge believer in all of them.

AI helps me write better code, generate tests, review pull requests and explore solutions much faster than I could a few years ago.

But AI only validates the scenarios we think to test.

Real users don't.

Some never touch a mouse.

Some navigate entirely with a keyboard.

Some use assistive technologies.

Some interact with software in ways we'd never think of while sitting at our desks.

No amount of automation can replace watching someone actually use your application.

Final Thoughts

Whenever people ask me about memorable production bugs, I don't think about distributed systems failures or obscure race conditions.

I think about a missing e.preventDefault().

One line of code.

A rollout that had passed every test.

And government service centres where staff couldn't help citizens because someone pressed Enter instead of clicking a button.

Sometimes the smallest bugs have the biggest impact.