The bug: a feature that worked everywhere except where it mattered
A new feature went into a web app's main file. Deployed, confirmed present on the actual server via a direct file check. Refreshed the browser — repeatedly, in incognito, on a different device. Nothing.
The file was correct. The server had the file. The feature simply wasn't there.
First instinct: it's caching
Hard refresh. Cleared browser cache entirely. Tried an incognito window — guaranteed no cache at all. Still nothing.
Checked whether the server itself might be caching an old version somewhere between disk and browser (a CDN, a reverse proxy). Fetched the file directly with a command-line tool, bypassing the browser completely: the new code was right there, in the actual response.
So the correct file was genuinely being served. And still, the feature didn't run.
Second instinct: something's silently failing inside the code
Added visible, unmissable debug messages directly inside the new function — the kind that pop up on screen, impossible to miss if the code runs at all.
Nothing appeared. Not even the most basic possible message, placed as the literal first line of the function.
Yet other code in that same file — code that had been working for weeks — was demonstrably still running correctly, fetching live data successfully.
The real diagnostic question
At this point, two things were true simultaneously: the file on the server was correct, and the code in that file wasn't executing. That's a genuinely strange combination — normally, if a browser has the right file, the code in it runs.
Unless the browser wasn't loading that file at all.
The actual root cause
Web servers have a long-standing default behavior: when someone visits a bare address with no specific filename, the server looks for a file conventionally named index.html and serves that automatically. It's such an old, ingrained convention that it's easy to forget it exists at all once a project has moved past its earliest setup.
This particular project had, at some earlier point, needed exactly this fixed — the bare domain was serving a different, separate file than the one everyone had been actively editing since. The fix at the time was to make a copy. That copy was never revisited. Every edit since then went only into the "real" file — the one being tested was always the untouched, months-old copy sitting quietly under the conventional default name.
The actual lesson
The instinct to suspect caching first is usually right — it's the most common cause of "I changed it and nothing happened." But caching has a specific signature: the server itself returns the new content correctly when checked directly, while the browser stubbornly shows the old thing.
Here, the server was also consistently serving something old — just a genuinely different file than the one being edited, not a stale copy of the same one. That distinction is the actual tell: if a direct server check confirms new content, but the live URL still shows old behavior, it's worth checking whether that URL is even resolving to the file you think it is, rather than assuming it must be some deeper, more exotic caching layer.
Sometimes the boring, first-year-of-web-development default is exactly what's happening — precisely because it's old and easy to forget.
Top comments (0)