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
- Call stop_flow to cancel the stale task that can no longer be resumed.
- Call submit_flow_input with a fresh description of what should happen next to restart the flow.
- If planned subtasks should still run, call get_flow_status (detail='tasks') to inspect the remaining plan.
- 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
- Gracefully shut down flows before backend restarts so paused subtasks are finalized.
- Avoid truncating/cleaning message tables while flows are active.
- Pin ask-checkpoint flows to stable database snapshots during maintenance.
- Automate the stop → fresh-submit recovery path in your agent loop.
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
- failed to submit flow input: %w
- token not found in database
- failed to create flow in DB: %w
- failed to get user %d: %w
- failed to get flow primary container: %w
AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01).
Data as JSON: /api/errors/f5f6ffb60671bb0b.
Report an issue: GitHub.