Failed session_commit archives cannot be listed or retried

Summary

When a session_commit background task fails, the session's raw content is archived server-side, but the client API has no way to list that archive or retry extraction from it. commit and extract both operate on the live message buffer only, which is already empty by the time anyone checks the failure — so a failed commit becomes permanently unrecoverable through the API, even though the data still exists.

Affected window

• 91 session_commit tasks reached terminal status: "failed", created between 2026-09-07T10:27:33Z and 2026-09-13T16:26:37Z (server: LXC 109, 192.168.2.183:1933, v0.4.19).
• Causes (first 50 sampled): 22× HTTP 429 (litellm-router rate limit), 17× HTTP 500, 6× request timeout, 4× HTTP 503 (backend model still loading), 1× StrPatch is not JSON serializable (server bug).
• Of 63 unique affected resource_ids checked individually, 55 show a server-side archive still present but marked failed (see reproduction below). The other ~5-8 had a genuinely empty archive (totalArchives: 0) or a live buffer to recommit from.

Reproduction

For any failed session_commit task, its resource_id is the session_id. Query the session directly:

GET /api/v1/sessions/{session_id}
GET /api/v1/sessions/{session_id}/context

Example (cc-04cf9396-10ee-4a6a-b484-827603fe3866, task dabca22f-0857-485e-8a00-b60232b228b5, failed with an HTTP 500 from the VLM backend):

{
  "message_count": 0,
  "total_message_count": 3,
  "commit_count": 1
}

"stats": {
  "totalArchives": 1,
  "includedArchives": 0,
  "droppedArchives": 0,
  "failedArchives": 1,
  "activeTokens": 0,
  "archiveTokens": 0
}

failedArchives: 1 proves the raw archive for the failed commit still exists. But:

• POST /api/v1/sessions/{session_id}/commit returns {"status": "skipped", "reason": "no_messages", "task_id": null} — no-op, because the live buffer is empty.
• POST /api/v1/sessions/{session_id}/extract returns {"result": []} — same no-op, same reason.
• There is no GET endpoint to list archive IDs for a session (only GET /api/v1/sessions/{session_id}/archives/{archive_id}, which needs an ID we have no way to obtain — it is not in the task record's meta/result, which are {} / null on failure).
• /api/v1/tasks/{task_id} has no retry action, only cancel.

Request

1. Expose archive IDs for a session (e.g. GET /api/v1/sessions/{session_id}/archives list endpoint), or include the archive_id in the failed task's meta.
2. Add a way to re-run extraction against one specific archive (failed or otherwise), independent of the live message buffer — e.g. POST /api/v1/sessions/{session_id}/archives/{archive_id}/retry.
3. Optionally, add a generic POST /api/v1/tasks/{task_id}/retry for any terminal-failed background task, so a caller does not need to reconstruct which resource/archive to resubmit.

Happy to share the full list of 63 affected resource_ids if useful.