The Connection That Died Quietly Every Four Hours

StackTube's notes are delivered through five channels. Email, Google Drive, Dropbox, Kindle, Obsidian. Users choose and connect based on where they want to read. Each time I built one of these five channels, I displayed a green "connected" indicator, and I trusted that green.

In EP.14 I wrestled with an ebook that came out blank. What I learned then was that "build success doesn't mean correct result." This case is the next chapter of that lesson. Back then, the failure was immediately before my eyes—open the book and it was blank. This time, the failure wasn't before my eyes. It appeared only after time passed.

As a pre-launch check, I had AI review this entire integration code. The first line of the results list read:

"The Dropbox connection will fail all uploads starting about 4 hours later. And that failure is reported nowhere."

Here's the content. When you connect to Dropbox, you receive a key. But this key lasts 4 hours. After 4 hours you must swap it for a new key, but there was no code to swap it. Right after connecting, everything is normal. Tests pass. Users are satisfied. And 4 hours later, the key expires, and every delivery after that fails.

Up to here, it's an ordinary bug. The real problem was the next sentence. The failure isn't reported. When a delivery failed, the system didn't raise an error—it quietly moved on to the next task. The indicator on the user's screen still read "connected." Green.

I imagined it. A user connects Dropbox, confirms the first few notes arrive fine, feels reassured, and forgets. From that afternoon, notes don't arrive. What does the user do when they open the folder a week later? Send an inquiry? Probably not. Most will think "something's off" and quietly leave. The system is silent, and the user is silent. Only I don't know.

"Only I don't know." This state was the core of this case. The bug itself—not refreshing a 4-hour key—is a common mistake. What's frightening is that the bug is invisible to me. The user leaves, the screen is green, and I believe the service is running well. While failure happens quietly, I'm under the illusion that I'm succeeding.

The same review surfaced several problems of a similar kind. A bug where English titles with a single quote—say, a video starting with Don't—broke the Drive search, causing the same note to be uploaded twice. A bug where the feature that moves a deleted note to an archive found nothing, because the filename it searched for differed from the actual filename, yet answered "done." All the same family. Things that failed but didn't say they failed.

The fix took less than three days. I added key-refresh code, made it retry once on failure, and attached a notification to every place that had been silent. Now, when a delivery fails, an alert comes to my Slack. Failure is no longer quiet.

After this case, my checklist gained one question. Before, I asked only "does this feature work?" Now I ask one more. "If this feature fails, how will I come to know?"

I learned from this case that the second question matters more than the first. The first question looks only at this moment. It's a confirmation of "it works now." But systems live in time. There's no guarantee that what works now works four hours later. A feature with no answer to the second question isn't working—it's just that the time to fail hasn't come.

For me, who can't read code, this is an especially urgent problem. A developer might look at the code and notice "there's no token refresh here." I can't. The only way I can know about a failure is to make the failure send a signal to me on its own. So for someone like me, detection devices—alerts, logs, monitoring—are even more essential than for a developer. Since I can't see the code, I have to make the code speak to me.

Four-hour keys are everywhere. Among the things that are green now, how many are merely not yet expired? I can't know them all. But now, at least, I try to make sure that when they die, they don't die quietly.

---

🔧 Technical Terms in This Episode

Access Token / Refresh Token Keys used to access external services. An access token is short-lived (Dropbox's is 4 hours), and when it expires, you must get a new key via the refresh token. This case was the absence of that "reissue code."

401 (Unauthorized) A response code meaning "the key is not valid." Whether you attempt reissue upon receiving this response, or quietly move on, was the fork in the road for this episode.

Observability The degree to which you can know a system's current state from outside. Logs, alerts, and monitoring are its tools. The question "if it fails, how will I know?" is this. The central concept of this episode.

Alerting / Monitoring Devices that automatically send a signal when a failure or anomaly occurs. Making an alert come to Slack when a delivery fails is an example. For an operator who can't read code, it's the only channel through which "the code speaks to me."

Retry Automatically re-attempting a task when it fails. Temporary failures (network drops, etc.) are often resolved by retry alone.