v1.0.0’s standalone mode had one clearly documented boundary: the in-memory queue lost unfinished tasks on process exit. v1.1.0 removes that boundary — without Redis, tasks now use a persistent database queue, so a restart no longer loses work.
A persistent queue that survives restarts
Without Redis, the task queue no longer lives in memory; it lands in database tables:
- SQLite: a new queue table (migration 000005), in the same file as the standalone database;
- PostgreSQL: a new queue table (migration 000024), in the same database as the business data.
The queue type is selected automatically by the database dialect, with no extra configuration. Tasks are claimed from the table, executed, and cleaned up when done; after an abnormal exit and restart, unfinished tasks are still recoverable.
Switchable queue
Setting redis.enabled=false enables the database queue, with semantics aligned to the Redis path: enqueue, retry, and dead-letter handling all go through the same queue interface. To switch back to the high-throughput Redis path, set redis.enabled=true.
For standalone and small-to-medium deployments, this means running without Redis while removing the risk of losing tasks.
Also fixed
- OIDC typed-nil interface panic: a runtime panic that could fire in standalone mode when OIDC config was missing — fixed.
- ~22% smaller binary: builds now strip symbol tables and debug info, so the download is smaller.
Verification
Concurrent processing and restart recovery are covered by PG integration tests, passed two rounds of code review, with zero PG regressions.