coleam00/Archon · error · Error

Node '${node.id}' cannot resume '${sourceNodeId}': the compl

Error message

Node '${node.id}' cannot resume '${sourceNodeId}': the completed source has no available provider session.

What it means

A node configured with a named session resume (`resume:` pointing at a completed source node) looks up that source node's recorded session handle in ctx.nodeSessionHandles. If the source completed but stored no handle at all, there is no provider session to fork, so the executor fails fast instead of silently starting a fresh session.

Source

Thrown at packages/workflows/src/dag-executor.ts:10428

              ctx.aiProfile,
              ctx.workflowPreset,
              resolveAiConfigText,
              ctx.warnedProviderConflicts,
              ctx.execContext
            );

            // 5. Determine session. An explicit named ancestor has first priority and
            // is independent of the ambient sequential cursor and parallel-layer reset.
            const namedResumeSourceNodeId = isNodeContextResume(node.context)
              ? node.context.resume
              : undefined;
            const hasNamedSessionResume = namedResumeSourceNodeId !== undefined;
            let resumeSessionId: string | undefined;
            if (hasNamedSessionResume) {
              const sourceNodeId = namedResumeSourceNodeId;
              const sourceHandle = ctx.nodeSessionHandles?.get(sourceNodeId);
              if (sourceHandle === undefined) {
                throw new Error(
                  `Node '${node.id}' cannot resume '${sourceNodeId}': the completed source has no available provider session.`
                );
              }
              if (sourceHandle.sessionId.trim() === '') {
                throw new Error(
                  `Node '${node.id}' cannot resume '${sourceNodeId}': the completed source has no available provider session.`
                );
              }
              if (sourceHandle.provider !== provider) {
                throw new Error(
                  `Node '${node.id}' cannot resume '${sourceNodeId}': source provider '${sourceHandle.provider}' does not match resolved provider '${provider}'.`
                );
              }
              const caps = ctx.deps.getAgentProvider(provider).getCapabilities();
              if (!caps.sessionResume || caps.sessionFork !== true) {
                throw new Error(
                  `Node '${node.id}' cannot resume '${sourceNodeId}': resolved provider '${provider}' does not support immutable session forks.`
                );

View on GitHub (pinned to 0773b97458)

Solutions

  1. Set persist_session: true on the SOURCE node so its provider session handle is recorded on completion
  2. Re-run the workflow from the beginning so the source node completes again and writes a fresh session handle
  3. Confirm the resume source node id matches exactly the node that completed in this run (not another run or renamed node)
  4. Check the store's getWorkflowNodeSession/persisted scope key configuration if handles are persisted across runs

Example fix

// before: source has no persist_session
- id: research
  prompt: "..."
- id: continue
  resume_from: research
// after
- id: research
  prompt: "..."
  persist_session: true
- id: continue
  resume_from: research
Defensive patterns

Strategy: validation

Validate before calling

const handle = ctx.nodeSessionHandles?.get(sourceNodeId);
if (!handle) throw new Error(`source ${sourceNodeId} has no session handle; set persist_session on it and re-run`);

Type guard

function hasSessionHandle(handles: Map<string, NodeSessionHandle> | undefined, id: string): handles is Map<string, NodeSessionHandle> {
  return handles?.get(id) !== undefined;
}

Try / catch

try {
  await engine.resumeFrom(runId, nodeId, sourceNodeId);
} catch (err) {
  if (err instanceof Error && err.message.includes('no available provider session')) {
    // re-run workflow so the source node records a handle
  } else throw err;
}

Prevention

When it happens

Trigger: Node B declares a resume from completed node A, but A ran with persist_session disabled, A's session handle was never recorded (e.g. A completed in an older run/attempt before handle persistence), or the handle map lost the entry across a run restart.

Common situations: Adding `resume_from`/named session wiring to a node whose source predates session persistence; resuming a run where the source node's handle was persisted under a different scope key; provider changed for the source so no handle was captured.

Related errors

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