vxcontrol/pentagi · critical · stateGuard

the waiting subtask's execution context is no longer availab

Error message

the waiting subtask's execution context is no longer available in the database — this typically happens after a system restart when the subtask was paused at an ask checkpoint. Recovery: (1) call %s to cancel the stale task; (2) call %s with a fresh description of what to do next; if the flow already has planned subtasks that should still run, use %s to inspect the remaining plan and %s to patch it before resuming

What it means

The flow had a subtask waiting at an 'ask' checkpoint, but when the input was submitted the subtask's message chain could not be found in the database ('no rows in result set'). The waiting subtask's execution context is gone — typically because the backend restarted or the DB was cleaned while paused — so the input cannot resume it. This is a permanent state error (stateGuard) requiring the flow to be stopped and restarted rather than retried.

Source

Thrown at backend/pkg/tools/flow_manager.go:760

				flowOperationTimeout, GetFlowStatusToolName)
		}
		// Flow is running (returned by sendAssistantFlowInput when status != waiting).
		// This is a transient condition — return a soft result so the LLM knows to call
		// stop_flow first instead of retrying indefinitely and crashing the chain.
		if strings.Contains(err.Error(), "not in 'waiting' state") ||
			strings.Contains(err.Error(), "cannot submit input") {
			return fmt.Sprintf(
				"Cannot submit input: the flow automation is currently active (not in 'waiting' state). "+
					"Call %s first to stop the current execution, wait for confirmation, "+
					"then retry %s. Use %s to confirm the flow is 'waiting' before retrying",
				StopFlowToolName, SubmitFlowInputToolName, GetFlowStatusToolName,
			), nil
		}
		// A missing message chain means the waiting subtask's execution context was lost
		// (most likely after a system restart or database cleanup while the subtask was at an ask checkpoint).
		// The subtask can no longer be resumed; the flow must be stopped and restarted.
		if strings.Contains(err.Error(), "no rows in result set") {
			return "", stateGuard(fmt.Errorf(
				"the waiting subtask's execution context is no longer available in the database — "+
					"this typically happens after a system restart when the subtask was paused at an ask checkpoint. "+
					"Recovery: (1) call %s to cancel the stale task; "+
					"(2) call %s with a fresh description of what to do next; "+
					"if the flow already has planned subtasks that should still run, "+
					"use %s to inspect the remaining plan and %s to patch it before resuming",
				StopFlowToolName, SubmitFlowInputToolName,
				GetFlowStatusToolName, PatchFlowSubtasksToolName))
		}
		return "", fmt.Errorf("failed to submit flow input: %w", err)
	}

	if waitingForAsk {
		return "Input delivered as the answer to the waiting subtask's question. The subtask will resume execution.", nil
	}

	// Input triggered task creation — wait for the generator to produce a running task.
	return t.waitForTaskReady(ctx)

View on GitHub (pinned to ea665308ba)

Solutions

  1. Call stop_flow to cancel the stale task that can no longer be resumed.
  2. Call submit_flow_input with a fresh description of what should happen next to restart the flow.
  3. If planned subtasks should still run, call get_flow_status (detail='tasks') to inspect the remaining plan.
  4. Use patch_flow_subtasks to fix/trim the plan before resuming.
Defensive patterns

Strategy: fallback

Validate before calling

// Detect an unresumable waiting subtask before submitting
if hasWaitingSubtask(ctx) && !messageChainExists(ctx, waitingSubtaskID) {
    // context lost: go straight to stop + restart flow
}

Try / catch

_, err := tool.Handle(ctx, "submit_flow_input", args)
if err != nil && strings.Contains(err.Error(), "no longer available in the database") {
    stopFlow(ctx, "stale ask checkpoint")
    submitFreshInput(ctx, "recovered task description")
}

Prevention

When it happens

Trigger: Calling submit_flow_input to answer a waiting subtask after a backend restart, DB cleanup/rollback, or data loss removed the message chain the paused subtask was resuming from.

Common situations: docker compose down/up or pod restart while an agent was paused waiting for user input; manual truncation of message tables; restoring the DB from an older snapshot mid-flow.

Related errors


AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01). Data as JSON: /api/errors/f5f6ffb60671bb0b. Report an issue: GitHub.