The Philosophical Developer — Chapter 07: The Three-Line Fix That Broke Three Tests

I had my padawan fix a bug in an open source Go library. Nothing unusual. He jumped in, found the problem, wrote a test, fixed it. Standard stuff.

Then a test broke. Then another. Then we found a composite filesystem was missing a pattern that a different one already had.

Three surprises across 20 minutes. The fix itself took three lines. The debugging took the rest.

The codebase was afero, a filesystem abstraction library for Go. It has two backends: an in-memory one (MemMapFs) and a real OS one (OsFs). The bug was straightforward: creating a file in a non-existent directory silently created the directory on MemMapFs, but returned an error on OsFs. Tests passed on the in-memory backend, then failed in production on the real one.

This is a classic abstraction leak. The in-memory backend was too permissive. Code that worked in tests broke in production because the mock environment was nicer than reality.

My padawan traced the code, found that registerWithParent was calling lockfreeMkdir on any missing ancestor directory, wrote a failing test, fixed it. Then the test suite revealed that TempFile and TempDir were relying on the buggy behavior. Then we found CacheOnReadFs.Create was missing a parent-directory check that CopyOnWriteFs already had. Each one was a domino that fell only when the previous one was fixed.

The fix was three lines. The blast radius was five files across two packages.

The full breakdown with numbers is on our fork branch fix/memmapfs-create-consistency.

What unreported bug in your dependencies is masking itself through lenient behavior?

Repos:

• afero fork — our fork with the fix branch

Also on LinkedIn.