28 lines
936 B
Markdown
28 lines
936 B
Markdown
|
---
|
||
|
|
id: "0004"
|
||
|
|
date: 2026-02-18
|
||
|
|
status: Accepted
|
||
|
|
supersedes:
|
||
|
|
superseded-by:
|
||
|
|
affected-paths: [taskq/queue.py, taskq/persistence.py]
|
||
|
|
affected-components: [queue, persistence]
|
||
|
|
---
|
||
|
|
|
||
|
|
# 0004 — Persist job queue to SQLite; survive process restarts
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
In-memory queue loses all pending jobs on restart. Clients resubmit, causing duplicates and lost work.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
All enqueued jobs persisted to local SQLite database (taskq.db). On startup, reload pending jobs from disk. Transaction isolation ensures no jobs are lost mid-processing.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Jobs survive restarts. Startup slower (disk IO). Must coordinate restart with in-flight execution to avoid double-processing. Query performance on large queues depends on SQLite optimization.
|
||
|
|
|
||
|
|
## Alternatives rejected
|
||
|
|
|
||
|
|
In-memory with RDB snapshots rejected: complexity without durability guarantee. Remote store (PostgreSQL) rejected: too heavyweight for single-user queue.
|