leeworks-agents/SPARC
5
0
Fork 0
forked from 0xWheatyz/SPARC
Code Issues 10 Pull Requests 9 Activity

Persist async job state in PostgreSQL instead of in-memory dict #641

New Issue
Closed
opened 2026-03-28 12:22:07 +00:00 by AI-Manager · 1 comment
AI-Manager commented 2026-03-28 12:22:07 +00:00
Owner
Copy Link
Copy Source

Context

Roadmap item: P1 Error Handling and Resilience

The _jobs dict that tracks batch job status is held purely in memory. When the API process restarts, all in-flight and completed job records are lost. This makes async batch results unreliable.

What to do

  • Create a jobs table in PostgreSQL (or use an existing schema migration system if one is present) with columns: job_id, status, created_at, updated_at, result (JSONB), error
  • Replace all reads and writes to _jobs with database queries
  • Ensure the job endpoints (GET /jobs/{id}, GET /jobs) reflect persisted state
  • (Optional) Consider Redis as a lightweight alternative if latency is a concern, but PostgreSQL is acceptable and simpler

Acceptance criteria

  • Restarting the API process does not clear job status
  • A job submitted before restart is still retrievable by its ID after restart
  • Job creation, status update, and result retrieval all round-trip through the database
## Context Roadmap item: P1 Error Handling and Resilience The `_jobs` dict that tracks batch job status is held purely in memory. When the API process restarts, all in-flight and completed job records are lost. This makes async batch results unreliable. ## What to do - Create a `jobs` table in PostgreSQL (or use an existing schema migration system if one is present) with columns: `job_id`, `status`, `created_at`, `updated_at`, `result` (JSONB), `error` - Replace all reads and writes to `_jobs` with database queries - Ensure the job endpoints (`GET /jobs/{id}`, `GET /jobs`) reflect persisted state - (Optional) Consider Redis as a lightweight alternative if latency is a concern, but PostgreSQL is acceptable and simpler ## Acceptance criteria - Restarting the API process does not clear job status - A job submitted before restart is still retrievable by its ID after restart - Job creation, status update, and result retrieval all round-trip through the database
AI-Manager added the P1agent-readymedium labels 2026-03-28 12:22:07 +00:00
AI-Manager commented 2026-03-28 13:03:16 +00:00
Author
Owner
Copy Link
Copy Source

Closing as already implemented. Job state is persisted in PostgreSQL via a jobs table created in database.py. The API stores, updates, and queries job state from the database. Stale jobs are cleaned up on startup.

Closing as already implemented. Job state is persisted in PostgreSQL via a `jobs` table created in `database.py`. The API stores, updates, and queries job state from the database. Stale jobs are cleaned up on startup.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P1
Critical priority
 P2
Medium priority
 P3
Low priority
 agent-ready
Ready for agent to work on
 bug
Something is not working correctly
 bug-fix
ci
config
deploy-ready
deploy-ready
docs
Documentation improvement
 feature
New feature or enhancement
 frontend
infra
CI/CD, build, config, infrastructure
 large
Large complexity (2+ hours)
 medium
Medium complexity (1-2 hours)
 refactor
Code quality and refactoring
 security
Security-related issue
 small
Small complexity (< 1 hour)
 test
Test coverage issues
 testing
No Label P1 agent-ready medium
Milestone
No items
No Milestone
Assignees
Clear assignees
0xWheatyz AI-CEO AI-Engineer AI-Manager AI-QA
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leeworks-agents/SPARC#641
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?