THE QUITE FAILURE

The worst bugs I've ever encountered aren't the ones that crash the application.

Crashes are honest. They announce themselves. They produce logs, stack traces, incident alerts. They interrupt the user so visibly that the bug report arrives within minutes. You know something is wrong, you know when it started, and the path to the crash site is usually short.

The bugs I'm talking about are different. They don't crash anything. The application keeps running, the UI stays responsive, the user keeps working and somewhere underneath, silently, everything they're doing is being thrown away.

I found two of those bugs in Clypra few days ago. They were sitting next to each other in the same codebase, following the same pattern, operating on the same principle: look fine, do nothing, destroy things quietly.

THE FIRST BUG

I was doing a lifecycle audit, not debugging a specific complaint, just trying to understand exactly what happens in Clypra when a user switches between projects. I had a document open, I was tracing the code path step by step, and about two hours in I hit a section of closeProject() that didn't look right.

There was a function call being made, a call that was supposed to reset the timeline to empty after a project closed. Nothing unusual about the intent. But the way it was written meant the reset happened asynchronously, without waiting for itself to complete before returning.

That sounds academic until you think through what it means in practice.

If a user closes Project A and then immediately opens Project B, the application loads Project B's data into memory correctly. The timeline fills with B's clips, B's tracks, B's entire editing history. Then, a few milliseconds later, after the code has already moved on, the reset from when Project A closed finally runs. And it doesn't know Project B has loaded. It has no way of knowing. It was started in a different context, and by the time it arrived, the world had changed.

So it wipes the timeline clean. Project B opens looking exactly as it should except for one thing: the timeline is empty. Not broken. Not crashed. Empty. The user assumes the load failed and starts recreating their work from scratch.

I sat with that for a while before I fully understood it, because the failure mode is so counterintuitive. The function that caused the damage had already returned successfully before it caused any damage. The harm came later, from a different execution context, triggered by work that started in a project that no longer existed.

The fix, when I found it, was a single word. But understanding why the fix was correct required understanding a principle I've seen in distributed systems literature, you cannot assume the context you started an operation in is still valid when it completes. The operation here was small, local, nothing resembling a distributed system in the traditional sense. But the race condition it created was structurally identical to the ones Kleppmann describes in DDIA when talking about async operations in multi-node environments. The producer and the consumer were running in different temporal contexts with no shared awareness of what had changed between them.

THE SECOND BUG

The second bug was quieter in a different way.

It lived in the auto-save layer. When a user drags a clip on the timeline, auto-save pauses, you don't want to write a half-finished edit to disk. When the drag ends, auto-save resumes and flushes whatever changes accumulated during the drag.

The mechanism that pauses and resumes auto-save is a flag, a single boolean, stored at the module level, shared across the entire application. It gets set to true when a drag starts and back to false when a drag ends. Simple, functional, and completely correct under normal usage.

But the teardown path, the code that runs when a project closes, doesn't know about this flag. It was never told. When I audited the reset function that's supposed to clean up all project state on close, the auto-save middleware wasn't in the list. Nobody had added it.

Which means there's a scenario where the flag gets left permanently set.

A user starts dragging a clip. Partway through the drag, before they release the mouse, they change their mind about the whole project and navigate back to the home screen. The application closes the project. The drag never ends, so the "drag ended" cleanup never runs. The flag stays set to true.

The user opens a new project. They make changes. They expect auto-save to work, because why wouldn't it? The UI gives no indication that anything is wrong. But every single save attempt goes through that flag, sees that it's set, and defers. The save never runs. It just keeps deferring, waiting for the drag to end that will never end, until the user closes the browser and loses everything they've done in that second project.

There's no error. No log. The application is healthy from its own perspective. The failure is entirely invisible.

CONCLUSION

When I put these two bugs next to each other, the pattern was immediately clear. Both were about state that was set by one thing and expected to be cleared by another, and the clearing path didn't know about the setting path. In one case the gap was temporal: the async operation resolved into a context it didn't belong to. In the other case the gap was structural: the teardown function that was supposed to clean up project state simply didn't have the auto-save flag on its list.

Both bugs were trivially fixable once found. That's usually how it goes with this class of bug. The fix is never the hard part. The hard part is that they're invisible until you go looking specifically for them and most teams never do.

The audit that found these took an afternoon. The bugs had been there for months.

What silent failure is sitting in your codebase right now, waiting for exactly the wrong moment?