The feature that never ran

I sold scheduled publishing in JamWidgets. It was in the UI, on the pricing page, and documented as a real feature.

It had never published a single post.

You could pick a time and save the post. It would sit there looking scheduled forever. No error. No failed task. No angry log line. The worker was healthy and the weekly digest ran on time.

Nothing crashed, which was the problem.

JamWidgets uses Underway for background work. Underway stores one schedule per queue. The queue name is the primary key, and calling schedule() again updates that row.

I had registered two schedules on the same queue:

• publish scheduled posts every minute
• send the owner digest every Monday

The second one replaced the first. Silently. The weekly digest worked and scheduled publishing ceased to exist.

This is obvious once you read the table definition. I had read the API and assumed “schedule another task.” The database meant “replace this queue’s schedule.” Those are very different sentences.

The usual monitoring was useless here. Failed jobs can alert. Retried jobs leave evidence. This job was never created, so there was nothing to fail and nothing to count.

The fix was boring: weekly work got its own queue and its own clock. That queue fans weekly tasks back onto the normal worker pool. Publishing keeps the minutely schedule. Two clocks, two rows.

The useful test was also boring. Start the app. Look at the schedule table. Confirm both rows exist. Then schedule a real post and wait.

I like job queues because they make failure visible. This one reminded me that they can only show work that reaches the queue.

“No failures” and “the feature works” are not the same metric.