you could tag a trip as weekly since basically day one. it would show up in the ui with a little repeat icon and everything. what it would not do, ever, under any circumstance, is actually repeat. you'd post your weekly walmart run, the week would pass, and it would just be gone — same as if you'd never checked the box.
nobody caught this for a few days because nobody was relying on it yet. but it's the kind of bug i find more embarrassing than a crash, because a crash at least tells you something's wrong. this just quietly did nothing while looking like it worked.
the fix took more thought than i expected. my first instinct was some kind of template row that generates copies of itself. i talked myself out of that, because then a "trip" would mean two different things depending on which table it came from, and every feature after this one — joining, editing, cancelling — would need two code paths instead of one. instead a recurring trip is a chain of perfectly ordinary trip rows that happen to share a series id. next week's occurrence is just another row. nothing downstream has to know or care that it's part of a series.
joins deliberately don't carry over from one occurrence to the next. agreeing to catch a ride this week isn't agreeing to every week going forward, and i didn't want to have to explain to someone why they got a notification about a ride they never said yes to.
so, a cron job that looks for series with nothing ahead of them and rolls the next occurrence forward. wrote it, tested it locally, deployed it. and every deploy after that quietly failed before the build even started.
turns out vercel's free tier only allows a cron to run once a day, and i'd scheduled mine hourly without thinking about it. the error was sitting right there in the deploy logs the whole time, i just hadn't gone looking, because why would you check deploy logs for a route you didn't touch. changed it to run once daily instead — the next occurrence is a week out regardless, so catching it within a day is more than enough slack — and scheduled it to run right before the digest, so a new occurrence can show up in that same day's summary instead of a day behind it.
two bugs, same feature, and neither one threw an error anyone would see. the first one just did nothing instead of erroring. the second one failed at deploy time, which is about as far from "a user reported it" as a bug can get. i think that's actually the harder kind to catch — nothing about using the app tells you it's broken, you have to already suspect something and go looking.
Comments (0)