What causes "Failed to find resumable run: ${err.message}" in coleam00/Archon?

Check the db.workflow_run_find_resumable_failed log's err and errorType fields for the driver cause.

Failed to find resumable run: ${err.message}

Error message

Failed to find resumable run: ${err.message}

What it means

findResumableRun locates a failed/paused run for a given workflow name and working path so it can be resumed instead of duplicated. DB failures are logged with rich context (err, errorType, workflowName, workingPath) under db.workflow_run_find_resumable_failed and rethrown wrapped in this message. No matching run returns null and does not throw.

Source

Thrown at packages/core/src/db/workflows.ts:836

  try {
    const result = await pool.query<WorkflowRun>(
      `SELECT * FROM remote_agent_workflow_runs
       WHERE workflow_name = $1
         AND working_path = $2
         AND ${resumableStatusClause(dialect, 3)}
       ORDER BY started_at DESC
       LIMIT 1`,
      [workflowName, workingPath, ORPHAN_RESUME_STALE_DAYS]
    );
    const row = result.rows[0];
    return row ? normalizeWorkflowRun(row) : null;
  } catch (error) {
    const err = error as Error;
    getLog().error(
      { err, errorType: err.constructor.name, workflowName, workingPath },
      'db.workflow_run_find_resumable_failed'
    );
    throw new Error(`Failed to find resumable run: ${err.message}`);
  }
}

/**
 * Find a resumable (failed/paused) run for a workflow scoped to (parent conversation, codebase).
 * Used by the orchestrator (all platforms) to detect approved runs that need foreground resume
 * on the prior run's worktree. Codebase scope prevents cross-project resume on persistent
 * chat conversation IDs (Telegram chat_id, Slack thread, etc.).
 *
 * Ordering is status-first, then recency WITHIN a status — not bare recency. The two statuses
 * are not interchangeable candidates for the caller: a `paused` run is an open gate that is
 * legitimately waiting and gets hydrated and resumed, while a `failed` one is deliberately gated
 * behind an explicit user prompt first (#1549). Ordering purely by `started_at` therefore lets a
 * newer failure shadow an older open gate, and approving that gate resumes nothing.
 *
 * Contrast with getActiveWorkflowRunByPath below, which sorts the opposite way (older-wins) —
 * it answers "who took the path lock first", a different question.
 */

View on GitHub (pinned to 0773b97458)

Solutions

Check the db.workflow_run_find_resumable_failed log's err and errorType fields for the driver cause.
Ensure migrations created workflow_runs with the columns the resumable query filters on (status, working_path).
Verify DB connectivity / SQLite file locking, then retry the read-only lookup.

Example fix

// before
const run = await findResumableRun({ workflowName, workingPath });
// after
let run: WorkflowRun | null = null;
try {
  run = await findResumableRun({ workflowName, workingPath });
} catch (err) {
  getLog().warn({ err }, 'resume_lookup_failed_starting_fresh');
}

Defensive patterns

Strategy: try-catch

Validate before calling

const ping = await pool.query('SELECT 1'); // DB reachable before resume detection

Type guard

function isFindResumableError(err: unknown): err is Error {
  return err instanceof Error && err.message.startsWith('Failed to find resumable run:');
}

Try / catch

try {
  const run = await findResumableRun({ workflowName, workingPath });
} catch (err) {
  // null means no resumable run (normal); throwing here means DB failure.
  getLog().error({ err }, 'resumable_probe_failed');
  run = null; // or rethrow if starting a duplicate run is unacceptable
}

Prevention

Remember null (no match) is success — never map null to the error path.
Run DB upgrades on every environment a workflow touches (including dev SQLite files).
Check SQLite file locking if using the SQLite adapter.
Alert on db.workflow_run_find_resumable_failed events.

When it happens

Trigger: Calling findResumableRun({ workflowName, workingPath }) when the database is unreachable, the workflow_runs table/columns are missing from an un-migrated DB, or the query times out under pool contention.

Common situations: Fresh install against an existing DB without running upgrades; SQLite file locked by another process; Postgres restarted between workflow steps; typos in DSN config in a secondary environment.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/f7826d77527e77c9. Report an issue: GitHub.