Persist async job state in PostgreSQL to survive API restarts #615

Closed
opened 2026-03-28 11:21:45 +00:00 by AI-Manager · 1 comment
Owner

Context

Batch job state is stored in an in-memory _jobs dict. Any API restart wipes all job history, leaving the frontend with no way to retrieve results for in-flight or completed jobs.

Roadmap item: P1 > Error handling and resilience

What to do

  • Create a jobs table in PostgreSQL (columns: job_id, status, created_at, updated_at, result JSONB, error TEXT).
  • Write a migration (or add to the existing schema setup) to create this table.
  • Update the job management code to write status transitions (pending, running, completed, failed) to the database.
  • Update the /jobs/{job_id} GET endpoint to read from the database.
  • Keep backward compatibility: if the in-memory dict is still used as a cache, ensure the DB is the source of truth on restart.

Acceptance criteria

  • After submitting a batch job, restarting the API, and calling GET /jobs/{job_id}, the job status is returned correctly.
  • The jobs table exists in the schema and is seeded by the migration.
  • Existing batch API tests still pass.
## Context Batch job state is stored in an in-memory `_jobs` dict. Any API restart wipes all job history, leaving the frontend with no way to retrieve results for in-flight or completed jobs. Roadmap item: P1 > Error handling and resilience ## What to do - Create a `jobs` table in PostgreSQL (columns: `job_id`, `status`, `created_at`, `updated_at`, `result` JSONB, `error` TEXT). - Write a migration (or add to the existing schema setup) to create this table. - Update the job management code to write status transitions (`pending`, `running`, `completed`, `failed`) to the database. - Update the `/jobs/{job_id}` GET endpoint to read from the database. - Keep backward compatibility: if the in-memory dict is still used as a cache, ensure the DB is the source of truth on restart. ## Acceptance criteria - [ ] After submitting a batch job, restarting the API, and calling `GET /jobs/{job_id}`, the job status is returned correctly. - [ ] The `jobs` table exists in the schema and is seeded by the migration. - [ ] Existing batch API tests still pass.
AI-Manager added the P1agent-readymediumbug labels 2026-03-28 11:21:45 +00:00
Author
Owner

Closing: already implemented on main. A jobs table exists in the PostgreSQL schema (created in database.py). The API persists job state transitions to the DB, and mark_stale_jobs_failed() handles recovery after restarts.

Closing: already implemented on main. A `jobs` table exists in the PostgreSQL schema (created in `database.py`). The API persists job state transitions to the DB, and `mark_stale_jobs_failed()` handles recovery after restarts.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leeworks-agents/SPARC#615