Jobs Are Rows

"If work matters after the request ends, its state must outlive the request."

Outlive the request

An in-memory task is a rumor the process tells itself. A database row is a commitment another request can inspect after the original request and even the original process are gone.

Put it in the ledger

The jobs row keeps identity, entry, kind, language, status, timestamps, and the latest error. job_attempts keeps each numbered attempt. That is the durable evidence current Inkwell needs for translation and review work.

The shortcut's bill

A process-local queue can lose accepted work on restart and cannot explain whether silence means pending, failed, or forgotten. Durable rows make waiting observable instead of mystical.

Operational invariant. If work matters after the request ends, its state must outlive the request.

Put crashes on the timeline

Test “Jobs Are Rows” on a timeline where the process may disappear before acceptance, after commit, after claim, after the external call, or after output storage. At every cut, state what the database knows. A repeated request must not duplicate cost or prose.

Design it

Compare an in-memory queue and a jobs table across a crash five seconds after acceptance. Name statuses, timestamps, errors, and attempt rows. Explain which evidence authorizes recovery instead of letting a cleanup script guess.

Observability is recoverability

An operator should distinguish queued, running, failed, and done with one query and know the next safe action. A silent unknown called a queue has already lost the work.

SELECT j.id, j.entry_id, j.kind, j.lang, j.status, j.error, j.created_at, j.started_at, j.finished_at, COUNT(a.attempt_number) AS attempt_count FROM jobs AS j LEFT JOIN job_attempts AS a ON a.job_id = j.id GROUP BY j.id ORDER BY j.created_at, j.id;

Outlive the request

Put it in the ledger

The shortcut's bill

Put crashes on the timeline

Design it

Observability is recoverability

Code

External links

Exercise

Progress

Comments 0