Back to blog
EngineeringMar 18, 2026· min read

Fixing What Never Worked: The Reminder Bug That Slipped Through

How a missing scheduler job and a silent TypeError kept Sabine reminders from ever firing—and what we learned about testing background jobs.

Sometimes the hardest bugs to find are the ones that never worked in the first place. This week we shipped a fix for Sabine reminders—a feature that, as it turns out, had never successfully fired a single reminder since launch.

What Happened

The issue was twofold. First, the background scheduler job responsible for checking and triggering reminders was never added to our task runner configuration. Users could create reminders through the UI without errors, but nothing was actually monitoring those reminders or firing them at the scheduled time.

Second, a TypeError in the reminder creation flow was silently failing in certain edge cases, preventing some reminders from being saved to the database at all. The error wasn't surfaced to users, so they had no indication their reminder hadn't been created.

Why It Matters

Reminders are a core feature of Sabine's AI partnership platform. They help users stay on top of conversations, follow-ups, and scheduled check-ins with their AI partners. When reminders don't fire, users lose trust in the platform's reliability.

This bug highlighted a gap in our testing strategy: we had unit tests for reminder creation and validation, but no integration tests that verified the end-to-end flow of creating a reminder, having the scheduler pick it up, and actually firing it. Background jobs are easy to overlook in test suites because they don't run synchronously with user actions.

What We Fixed

We added the reminder scheduler job to the task runner's job registry and verified it runs on the expected interval. We also fixed the TypeError in the creation flow by adding proper type validation and null checks. Finally, we added integration tests that create a reminder, advance the scheduler clock, and verify the reminder fires as expected.

What's Next

We're auditing all background jobs in Sabine to ensure they have corresponding integration tests. We're also adding observability for scheduled jobs so we can monitor their health and catch failures before users report them.

Longer term, we're building a job dashboard into Strug Central that will give us real-time visibility into all scheduled and background jobs across Strug City products. If a job stops running or starts failing at high rates, we'll know immediately.

The best bugs are the ones that teach you something. This one reminded us that autonomy and intelligence require robust testing at every layer—especially the invisible ones.