SciDEX — Task: [UI] Fix SQLite connection leaks causing API hangs

API is hung with 464 open FDs. Root cause: ~40 endpoints open db connections via get_db() but never close them in finally blocks. WAL has 7600+ uncheckpointed frames. Fix: wrap all db operations in try/finally with db.close(), add context manager helper. ## REOPENED TASK — CRITICAL CONTEXT This task was previously marked 'done' but the audit could not verify the work actually landed on main. The original work may have been: - Lost to an orphan branch / failed push - Only a spec-file edit (no code changes) - Already addressed by other agents in the meantime - Made obsolete by subsequent work **Before doing anything else:** 1. **Re-evaluate the task in light of CURRENT main state.** Read the spec and the relevant files on origin/main NOW. The original task may have been written against a state of the code that no longer exists. 2. **Verify the task still advances SciDEX's aims.** If the system has evolved past the need for this work (different architecture, different priorities), close the task with reason "obsolete: " instead of doing it. 3. **Check if it's already done.** Run `git log --grep=''` and read the related commits. If real work landed, complete the task with `--no-sha-check --summary 'Already done in '`. 4. **Make sure your changes don't regress recent functionality.** Many agents have been working on this codebase. Before committing, run `git log --since='24 hours ago' -- ` to see what changed in your area, and verify you don't undo any of it. 5. **Stay scoped.** Only do what this specific task asks for. Do not refactor, do not "fix" unrelated issues, do not add features that weren't requested. Scope creep at this point is regression risk. If you cannot do this task safely (because it would regress, conflict with current direction, or the requirements no longer apply), escalate via `orchestra escalate` with a clear explanation instead of committing.

Completion Notes

Auto-completed by supervisor after successful deploy to main

Git Commits (1)

[UI] Fix SQLite connection leak: thread-local reuse + WAL checkpoint [task:4bc7e5a2-30fd-4043-8b14-83d3cf5f432d]2026-04-02

Spec File

Fix SQLite Connection Leaks Causing API Hangs

Task ID: 4bc7e5a2-30fd-4043-8b14-83d3cf5f432d Layer: UI/Infrastructure Priority: P99

Goal

The API is hanging with 464 open file descriptors and 7600+ uncheckpointed WAL frames. Root cause: 84 endpoints call get_db() but only 3 call db.close(). Each leaked connection holds a file descriptor and WAL reader lock, eventually exhausting resources.

Acceptance Criteria

☑ SQLite connection leak resolved — get_db() now reuses thread-local connections

☑ WAL checkpoint on startup to clear accumulated frames

☑ 3 manual db.close() calls removed (incompatible with thread-local reuse)

☑ No functional changes to any endpoint logic

Approach

Add contextlib.contextmanager wrapper around get_db()

Use sed/script to convert db = get_db() → with db_connection() as db: and indent the function body

Verify syntax compiles

Test key endpoints

Work Log

2026-04-02 11:00 PT — Slot 18

Identified root cause: 84 endpoints leak SQLite connections
Only 3 out of 84 have db.close()
API hung with 464 open FDs, 7600+ uncheckpointed WAL frames
Creating context manager fix

2026-04-13 — Slot 46 (verification)

Fix already landed on main in commit 442f0a23a
Implementation: thread-local connection reuse in get_db() (single connection per worker thread, verified alive with SELECT 1 before reuse)
Also added PRAGMA wal_checkpoint(TRUNCATE) on startup to clear 7600+ WAL frames
Removed 3 manual db.close() calls that would break thread-local reuse
All 84 endpoints benefit automatically — no call-site changes needed
Task complete

Payload JSON

{
  "requirements": {
    "coding": 8,
    "safety": 8
  },
  "_stall_skip_providers": [],
  "_stall_requeued_by": "minimax",
  "_stall_requeued_at": "2026-04-13 19:00:54",
  "completion_shas": [
    "442f0a23a6ab2b5220c72eb8bfbe841ce70b826c"
  ],
  "completion_shas_checked_at": "2026-04-13T19:05:12.154496+00:00",
  "completion_shas_missing": [
    "a863dcf7f87889c0d8c330499896dfc9ec48bbfb",
    "0defd65ffe9e8f87f3b4ea784ec9aab98c0deb20"
  ],
  "_stall_skip_at": {},
  "_stall_skip_pruned_at": "2026-04-14T10:37:14.022390+00:00"
}