Back to all posts

How I Debugged the Weirdest Bug of My Career

4 min read

How I Debugged the Weirdest Bug of My Career

Every developer has at least one story like this — the kind that makes you question reality, your sanity, and sometimes the laws of physics.

This is mine.

The Symptom

It started with a Slack message from a QA engineer:

"Hey, I think our app just translated itself into Portuguese??"

I laughed. Then I saw the screenshot. It was real. A completely unrelated section of our web app — one that had nothing to do with internationalization — was suddenly showing Portuguese labels.

Even weirder: only on Tuesdays, only in production, and only for users on Firefox.

The Setup

We were running a large React app with server-side rendering, i18n support, and a custom build process. Locale files were loaded dynamically depending on the user’s language settings.

Everything was built using Webpack, deployed on Vercel, and cached with aggressive CDN headers.

Here’s what made the bug particularly bizarre:

  • Our default language was English.
  • We did not support Portuguese.
  • Our Accept-Language parsing logic didn’t even recognize pt-* locales.
  • The source code didn’t include a single Portuguese word.

The Rabbit Hole

My first instinct was to grep for Portuguese. Nothing.

Next, I tried reproducing it — no luck. Not locally, not in staging, not even in production on Chrome.

I started logging server responses and client state. On the rare occasion it did happen, the page would briefly flash in English, then re-render some parts of the UI in Portuguese — specifically button labels and tooltips.

I added network logging. I captured request headers. I diffed HTML. I even spun up an AWS instance just to simulate browsing from Brazil on Firefox on a Tuesday. Still nothing.

At this point I genuinely started to wonder if I was being pranked.

The Breakthrough

Out of desperation, I asked QA to screen-record their dev tools. On one fateful Tuesday, they caught a clue.

Right before the UI switched languages, the app was dynamically loading a chunk:

/_locales/pt/tooltip.bundle.js

Wait… what?!

We didn’t have a pt locale. But somehow, Webpack was generating a pt chunk anyway.

The Culprit

Turns out, the bug had two causes:

  1. A stale pt.json file in our Git history that had been deleted months ago — but not from the build cache.
  2. Webpack's dynamic import pattern was matching import(\./locales/${lang}/tooltip.js`), and during build, it included all possible folders under locales/`, even ones that no longer existed in the repo but still existed in older deployment cache artifacts.

Bonus: On Tuesdays, our CDN purged part of its cache as part of a traffic throttling script.

So on Tuesdays, some edge nodes were missing the English fallback and instead served stale Portuguese bundles from a backup cache.

Firefox’s caching strategy + older HTTP headers allowed it to load these cached files. Chrome didn’t.

The Fix

We:

  • Manually purged all old bundles from the CDN
  • Reconfigured Webpack to only include locale files explicitly listed
  • Added tests to verify that no unsupported locales are being bundled
  • Deleted the stale pt folder in all environments

And… the bug never came back.

What I Learned

  1. CDN edge caching can behave like a mischievous time machine.
  2. Webpack will bundle more than you think — unless you tell it not to.
  3. Bugs that involve timing, caching, and internationalization are rarely simple.
  4. Sometimes, the weirdest bugs require stepping back and asking what else could possibly be involved — even if it feels absurd.

Have you ever debugged something so strange it made you doubt your reality? I'd love to hear your stories — misery loves company.