Self-Hosted on onelegdave.dev

Tested. Deployed. Wrong Anyway.

OneLegDave — Sat, 05 Sep 2026 09:00:00 -0700

Same medication tracker as last time, different day, different problem. This one isn’t about the app going dark. It’s about everything technically working and still being wrong.

147 tests. Nearly 2,000 lines of Kotlin. Everything green. I deployed it, used it for real for about ten minutes, and found four separate ways it was lying to me, none of which a single one of those 147 tests could ever have caught, because they weren’t bugs in what the code did. They were bugs in what the running app was telling a human standing in front of it.

Arithmetic first, because the rest doesn’t matter if this is wrong

Before any database, any HTTP, anything, I wrote the days-remaining math as plain Kotlin with zero dependencies, because if this number’s wrong, the app isn’t useless, it’s actively dangerous. Confidently wrong about whether you’re about to run out of insulin is worse than not having an app at all.

The spec had it as two separate divisions to average weekly and as-needed doses onto one timeline. I collapsed both into one exact fraction, floored once, instead of doing the math in floating point:

days_remaining = floor( units * 210 / (weekly * 30 + prn_total * 7) )

Not being clever for the sake of it. Binary floating point flat-out gets this wrong on exact boundaries: 4.5 units on hand, 4.5 used weekly, the honest answer is 7 days, and a Double hands you 6. I swept roughly 56,000 schedule combinations against exact rational math to check. About 0.2% disagreed, always off by exactly one, always sitting right on a boundary. Rare enough to sail through code review unnoticed. Common enough to flip a real alert on a real person.

There’s now a test that asserts the naive floating-point version returns the wrong number on purpose, so future-me, or anyone else who thinks they’re “simplifying” this, finds out immediately why it’s written the ugly way.

Breaking my own tests on purpose

Here’s the practice that earned its keep hardest, and it’s embarrassingly simple: for anything a test claims to guard, break the actual mechanism on purpose and confirm the test goes red. Then put it back.

Sounds like paranoid busywork. It caught four tests that were passing for entirely the wrong reason, quietly guarding nothing, forever, until I forced the question.

Moved the error-catch inside the transaction. Ten repeat taps took stock down to 50 instead of 59. SQLite aborts the one bad statement, not the whole transaction, so a failed deduction silently committed without its matching dose row. Three tests caught it, that’s a test doing its job.

Deleted the HTTP method guard in the service worker. Every test still passed. Turns out every write case in the test suite happened to route through /api and got caught by a completely different check, so that guard was dead weight nobody would’ve noticed missing until it mattered.

Deleted the offline navigation fallback. Still green. The tests requested /, which is precached and always resolves fine, but Android tacks a query string onto start_url on a real home-screen launch, and cache matching compares the full URL including that string. A real phone launch would’ve missed the cache entirely and gotten nothing, while every single test sailed past it.

Disabled the SQLite foreign-key pragma. Exactly one test failed, which is the correct outcome, and the one I actually wanted to see. Foreign keys are off by default in SQLite, enabled per-connection, and any connection that forgets the pragma just quietly accepts orphaned rows forever.

Two of those four had the actual mechanism removed and the suite stayed green. A green test suite proves the tests ran. It proves nothing about the code until you’ve personally watched each one fail for the reason it claims to exist.

Things only the real server was rude enough to tell me

Ran clean locally. Deployed to the actual box and immediately hit three problems no amount of local testing was ever going to surface.

A tmpfs mounted noexec. First run died instantly: UnsatisfiedLinkError: failed to map segment from shared object. The SQLite driver extracts its native library to the JVM temp directory and loads it from there. Docker mounts --tmpfs noexec by default, so the load just failed on the very first database open. The error message says nothing whatsoever about mount flags. /tmp is now mounted exec, with a comment explaining exactly why, because the “obvious” future hardening move is a crash loop.

A port that was already spoken for. Installing to a phone needs a service worker, which needs a secure context: HTTPS or bust. Plain HTTP over the tailnet serves the app fine and just silently never offers to install, no warning. So: real cert via Tailscale Serve, which defaults to 443, except 443 on that box was already doing something completely unrelated. Publishing there would’ve shadowed an existing service’s cert and taken it down as a side effect of deploying a medication app, which is the kind of blast radius nobody signs up for on purpose. Moved to a different port. Costs nothing, a secure context cares about scheme, not port number.

Compose stacks that fail without telling anyone. On that server, containers aren’t wrapped in systemd units, they lean entirely on Docker’s own restart policy. Which means a crash-looping container restarts forever, silently, and nothing ever reports it. I’d written that exact fact down months earlier and completely forgotten I had. A dead media server is obvious the second you try to watch something. A dead medication tracker is invisible until the specific morning you go to check it and it isn’t there.

Fix ended up being the nightly low-stock alert script, since that one does run as a proper systemd timer with real failure notification wired up, but only if it’s built to actually notice a dead server instead of politely assuming an empty response means everything’s fine:

ALERTS="$(curl -fsS --max-time 20 "$API/api/alerts")"

That -f flag is doing the entire job. Without it, a dead container hands back an error page, the script parses zero alerts out of it, and reports “all clear” every single night the app is down. Silence dressed up as reassurance. The gap between a real alerting system and one that just resembles one was a single missing character in a shell script.

I didn’t just trust that. Stopped the container, ran the check by hand, watched it die with exit 7, watched systemd catch the failure, watched the notification land on my phone. Good time to prove that chain: database was still empty.

What ten minutes of actually using it found

Everything above, tested and proven. Then I installed it for real, put in my actual medications, and tapped “take all” for the morning. Four bugs inside ten minutes, and not one of them was about what the code computed. Every single one was about what the app told a person looking at the screen.

Offline hung instead of failing. Airplane mode, app opens to its splash screen, and just… stays there. Forever. No app, no error, nothing. An unreachable server on a tailnet doesn’t always politely refuse the connection. The name still resolves, nothing rejects the socket, the fetch just never resolves either way. My service worker was awaiting it with zero timeout, so the whole page had nothing to render and nothing to say. Every network call now has an actual number on it. Reads give up after 4 seconds since someone’s standing there waiting and a read is cheap to retry, writes get 8 because a timed-out write might have landed and the only honest move is to make you go check.

A blank screen making a claim it hadn’t earned. With the hang fixed, it correctly showed a red “can’t reach server” banner, sitting directly above a completely empty medication list. Which is the single worst thing this specific app is allowed to display, because an empty list and “nothing due today” are visually identical, and one of those two things at six in the morning is dangerous to get wrong. Fixed: no list is ever blank by default now. Loading says loading. Failure says failure, explicitly, as “can’t reach the server,” never silently rendered as an empty day.

Doses landing on the wrong calendar day. Tapped “take all,” and it logged against yesterday. Today then cheerfully offered to let me take everything again, since as far as it could tell, nothing had happened yet. The write itself was fine, stock even decremented correctly, the client had simply sent the wrong date. I never fully pinned down how it drifted onto the wrong day, so the fix targets the whole category rather than one cause: a loud banner when you’re not viewing today, a confirmation before bulk-logging against a past date, and the fix that’ll actually matter, following the real date across a midnight rollover on resume, since this is an app that gets opened right before bed and first thing in the morning.

The fourth bug that day was the app going completely dark on every device while the server was perfectly healthy. That one got its own post, The Server Was Never Down.

The default I refused to ship

Last thing that came out of actually using it: an as-needed medication was projecting 690 days remaining on a bottle of ibuprofen. Technically derived correctly from the math. Read as complete nonsense the second a human looked at it, because a rate based on whatever happened to occur in the last thirty days swings wildly on a single dose and dresses that swing up as precision it doesn’t have.

Fix: as-needed medications alert on raw units left instead of a days projection. That also patched a hole nobody had noticed. Under the days-based rule, an as-needed medication with nothing logged in the past month has no projection at all, and a null projection never alerts, so it could sit at two tablets left and say absolutely nothing about it.

The migration wanted a sensible default threshold backfilled onto every existing as-needed medication, ten units seemed reasonable. Checked it against the real data before shipping it, because “seemed reasonable” is not a threshold, it’s a guess wearing a lab coat:

Gabapentin 64 units
Lispro (Insulin) 1385 units <- 10-unit threshold

A ten-unit warning on 1385 units of insulin would functionally never fire, on the exact medication my own original spec singled out by name as the one where running short is not a minor inconvenience. Ten’s fine for a bottle of tablets and dangerously wrong for that. There is no single default that’s safe across both, so the migration adds the column and backfills nothing. Existing meds keep their days-based threshold until a real number gets chosen for each one, and the reasoning’s written directly into the migration file so nobody “helpfully” finishes the job for me later without reading why it was left undone.

Worth naming the general shape of that mistake: a default is a decision made on someone else’s behalf without knowing their actual situation. Usually that’s a harmless convenience. The moment that number is the thing deciding whether a warning fires at all, it stops being convenient and starts being a bet you didn’t ask permission to make.

Breaking my own rule, on purpose, in writing

That change directly contradicted a line in my own spec, filed under a heading that literally said settled, do not reopen during implementation. That rule exists for a good reason: it’s there to stop you relitigating design decisions mid-build out of boredom or anxiety.

But that rule was written before the thing existed, and actually running it produced evidence that plain didn’t exist at the time I wrote the rule down. So I reopened it anyway, and documented in the spec itself that it was reopened, when, and specifically why, instead of just quietly contradicting a document I’d told myself not to touch. The original math was never wrong. It was unhelpful in a way you can only discover from the far side of a system that actually runs.

147 tests, all green, the whole time. None of them were ever going to catch a number that was correct and useless, a screen that was blank and honest at the same time, or a default that was reasonable for one drug and reckless for another. That’s not a gap in the test suite. It’s the actual, permanent boundary of what a test suite can tell you: it verifies what code does. Only running the thing in front of an actual person tells you what it means to them.

The Server Was Never Down

OneLegDave — Fri, 04 Sep 2026 10:00:00 -0700

I built myself a medication tracker. Single user, me, running on my own server, reachable only over my own private network. Not a health app in the App Store sense — no dose advice, no interactions, no clinical logic anywhere in it. It counts what I have, tells me what’s due, and yells at me before I run out. That’s the entire scope, on purpose, because the second a personal project starts pretending to be a doctor is the second it becomes a fucking liability instead of a tool.

I finished it. Deployed it. Started actually using it for real medications, which is the part that matters — a supply tracker that only ever gets tested with fake data hasn’t actually been tested for shit. And within days it started telling me it couldn’t reach the server. From my phone. From my desktop. Every device, same error, connection refused, like the whole thing had just died in the night.

The server had not died in the night. The server had never been healthier. I was staring at a goddamn ghost.

Guilty until proven guilty

First instinct, obviously: check the server. It was fine. Container healthy, every endpoint answering, curl from a completely different device on the network getting clean 200s back like nothing was wrong, because nothing fucking was.

Second instinct: check the network. Also fine. Nothing had changed there in weeks.

Third instinct, the one that should embarrass me a little: assume the phone was lying, restart it, uninstall the app, reinstall it from the home screen, watch it fail exactly the same way, immediately, with total confidence, like it had done this before.

It had done this before. It had done this every single time, because the thing I was reinstalling wasn’t actually broken — it was faithfully, perfectly doing exactly what a Progressive Web App is designed to do, and the design was the fucking problem.

The ghost was mine

Here’s the part that stung once I found it: a PWA doesn’t get installed from an app store with a name and a version number. It gets installed from a URL, and it stays bound to that exact origin forever. Not the app. The address. Reinstalling doesn’t fix a stale origin, it just re-commits to the same dead one, because as far as the phone’s concerned that origin is the app’s whole identity.

Months earlier, before there was anywhere real to deploy this thing, I’d stood up a quick throwaway address on my laptop just to test how the layout looked on an actual phone screen instead of squinting at a browser window pretending to be one. Totally reasonable thing to do. Tore it down the moment real deployment happened, also totally reasonable. Except at some point during that testing, I’d installed the damn thing to my home screen from that scratch address, and never thought about it again, like a dumbass.

So the icon on my phone was never talking to the server. It had never once talked to the server. It had been faithfully, patiently trying to reach a machine that stopped listening for that address weeks ago, and every single time it failed, it failed with an error that is byte-for-byte identical to “the server is down.” ERR_CONNECTION_REFUSED doesn’t editorialize. It doesn’t say “hey, this domain doesn’t exist anymore, you absolute muppet, might want to check that.” It just refuses, flatly, and leaves you to guess why.

Fixed by pointing the install at the actual live address and pinning that URL somewhere obnoxiously obvious so future-me doesn’t get to relive this shit.

What the silence was hiding

Here’s where it stopped being embarrassing and started being useful. The server had no access log. None. Which meant when this started, I had zero way to tell the difference between “the phone tried to connect and got rejected” and “the phone never tried at all.” Those are completely different failures with completely different fixes, and I couldn’t tell them apart because I’d never built the thing that would let me.

So I added one. And the very first thing it proved was that every single entry in it, for the entire time this had supposedly been “down,” was the container’s own healthcheck pinging itself every thirty seconds like clockwork. Nothing else. No failed request. No rejected connection. Not one single byte from my phone had ever arrived, because it was never being sent anywhere near this fucking machine in the first place.

That log — something I only built because I got burned — is also what turned up two real bugs hiding underneath the fake one, which is exactly what happens when you finally go looking properly instead of vibing it. The app’s reconnection logic was trusting the browser’s online event to know when the network came back, and that event is basically decorative on a phone — so a genuinely brief network drop could get treated as permanent, forever, until you manually intervened like an idiot. And separately, when the app did recover, it only bothered refreshing two of its three screens and left a stale “can’t reach server” panel sitting on the third, so even a fully working reconnect still looked broken if you happened to glance at the wrong tab.

Neither of those caused the outage. Both would have made a real outage worse, invisibly, and I only found them because a fake one forced me to build the tooling to actually see what was happening instead of guessing at it.

The pattern underneath all of it

I’d already built this thing around one rule, from the start, mostly out of paranoia: nothing in this app is allowed to be blank or silent by accident, because for a medication tracker, blank and silent both read as “nothing to worry about,” and that’s exactly the one lie this app is not allowed to tell, ever. An empty list has to mean the server confirmed there’s nothing due — never “the request hasn’t come back yet” wearing an empty list’s clothes like a coward.

This whole outage was that exact philosophy failing at a layer I hadn’t built it into yet. The client had no way to say “I am not even reaching the network you think I am,” so it said nothing, and nothing looks exactly like everything being fine, which looks exactly like everything being fucked, depending on which side of the silence you’re standing on. A dead request and a healthy one that just hasn’t finished look identical if you never bother asking which one you’re actually looking at.

Turns out the same rule that governs whether an empty dose list can be trusted also governs whether “can’t connect” means what you think it means. Silence is never neutral. It’s just a claim wearing a disguise, and the whole job is making sure the disguise never fucking fits.