submit timed out after %s — the flow may not have received t

Error message

submit timed out after %s — the flow may not have received the input. Call %s to check the current state before retrying

What it means

The flow input handler (sendAssistantFlowInput) did not return within flowOperationTimeout, or its context was cancelled, so the tool reports that the input may not have been delivered. Because delivery is uncertain, the tool refuses to claim success and directs the caller to check flow state before retrying. This avoids double-submitting input on an ambiguous timeout.

Source

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

	// Determine mode for better response message
	waitingForAsk := false
	subtasks, err := t.db.GetFlowSubtasks(ctx, t.flowID)
	if err == nil {
		for _, st := range subtasks {
			if st.Status == database.SubtaskStatusWaiting {
				waitingForAsk = true
				break
			}
		}
	}

	inputCtx, inputCancel := context.WithTimeout(ctx, flowOperationTimeout)
	defer inputCancel()

	if err := t.handler(inputCtx, action.Input); err != nil {
		if errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) {
			return "", fmt.Errorf(
				"submit timed out after %s — the flow may not have received the input. "+
					"Call %s to check the current state before retrying",
				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).

View on GitHub (pinned to ea665308ba)

Solutions

Call get_flow_status to see whether the input was actually received before doing anything else.
If the flow is still in 'waiting' state, re-call submit_flow_input with the same input.
If the flow is running, the input likely arrived — do not resubmit; wait or call stop_flow if needed.
Increase flowOperationTimeout if slow LLM/worker responses routinely cause false timeouts.

Example fix

// before: blindly retrying on timeout
if _, err := tool.Handle(ctx, "submit_flow_input", args); err != nil {
    tool.Handle(ctx, "submit_flow_input", args) // risk of double-delivery
}
// after: check state first, retry only if still waiting
if _, err := tool.Handle(ctx, "submit_flow_input", args); err != nil {
    status := getStatus(ctx) // get_flow_status
    if status == "waiting" {
        tool.Handle(ctx, "submit_flow_input", args)
    }
}

Defensive patterns

Strategy: validation

Validate before calling

// Only resubmit when the flow is verifiably still waiting
status := getFlowStatus(ctx)
if status != "waiting" {
    return // input likely delivered or flow busy — do not resend
}

Try / catch

_, err := tool.Handle(ctx, "submit_flow_input", args)
if err != nil && strings.Contains(err.Error(), "submit timed out") {
    // ambiguous outcome: check state before any retry
    if getFlowStatus(ctx) == "waiting" {
        _, _ = tool.Handle(ctx, "submit_flow_input", args)
    }
}

Prevention

Never blindly retry an input submit after a timeout — always check flow state first.
Tune flowOperationTimeout to exceed worst-case LLM/worker latency.
Avoid submitting input concurrently with a running task.
Log flow state transitions to diagnose ambiguous deliveries.

When it happens

Trigger: Calling submit_flow_input while the flow automation channel is slow or the assistant goroutine is blocked, so t.handler(inputCtx, input) exceeds flowOperationTimeout or the parent ctx is cancelled mid-submit.

Common situations: LLM provider latency or the flow worker being busy when the input is sent; submitting input concurrently with a running task; very short flowOperationTimeout configuration; operator cancelling the agent run mid-submit.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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