Five bugs from my solo projects that never threw an error
I build solo, with coding agents doing most of the typing. Going through this week's threads here, I noticed the bugs that cost me the most had one thing in common: nothing crashed, nothing logged, and no user would ever have reported them.
1. Tests that couldn't see the risk. My API's pytest suite runs on SQLite, which has no Postgres row-level security or triggers. Green every time. Now I check RLS by hand with psql, as anon and as a logged-in user, inside BEGIN...ROLLBACK.
2. Production that didn't match the repo. Every migration was correct and local Supabase was clean, but the hosted project had broad default grants from provisioning that no migration ever revoked. A column meant to be private was readable without login. Now I compare the live grants against the schema files after setting up any hosted project.
3. Production quietly behind main. 19 migrations had never been applied, and 32 others had identical SQL under different version numbers, so a blind db push would have failed on the first one. Now amigration only counts as done when it's applied to local and production in the same task.
4. An error that looked like an answer. The wrapper around a Go engine parsed the engine's error replies as moves. GTP starts success with "=" and failure with "?", and nothing checked which one came back. There's now a test that feeds it a "?" and expects an error.
5. A loop nobody multiplied. A monitor in my Polymarket bot re-downloaded 200 trades every 20 seconds to find zero or one new one: 8.6 GB of proxy traffic. Gzip, pages of 20 and a 60-second poll cut it about 100x. None of these was hard to fix. All of them were hard to notice.
What's a bug in your project that never threw an error? And what check would have caught it earlier?
Replies
A coding agent wrote an analytics summary that output a completely believable metric. It threw zero errors, so an entire day went into hunting downstream calculation bugs before opening the generator script and finding the model had just hardcoded a placeholder return value.
@konstantin_tikhaev That's the worst version, because a believable number sends you debugging everything except the thing that produced it. Did you add a check after that?
The cheapest one I can think of for that case: change the input and assert the metric moves. A hardcoded return fails it on the first run.
@wwenioaguiar The test uses two synthetic datasets with different scales to verify the output actually shifts between runs.
Number 3 has a cousin I hit with Firebase: a freshly deployed event trigger quietly drops events for its first minute or two. A song created 45 seconds after the deploy was never picked up, no error anywhere, it just sat in "queued". One created five minutes later went through fine. Now a new trigger gets a few minutes before anyone tests it, and anything stuck in queued gets created again. Your rule that a migration only counts once it's applied everywhere is a good one, I'd add "and after you've watched one real event go through". Which of the five took you longest to find?
Production is where it bites me too. With Next.js I used to build on the production server, but the server wasn't that powerful and the site was unusable while it built. Since then I build locally on my MacBook Pro M4 Max and just transfer the result, and it's been smooth.