Significant-Gravitas/AutoGPT · error · HTTPException

Execution not found or not in QUEUED status

Error message

Execution not found or not in QUEUED status

What it means

HTTP 404 from the admin execution-requeue endpoint. get_graph_executions was called with graph_exec_id AND statuses=[AgentExecutionStatus.QUEUED]; an empty result means either no execution exists with that id, or it exists but is no longer QUEUED (already RUNNING, COMPLETED, FAILED, or STOPPED). Requeue is only valid for executions stuck in the queue.

Source

Thrown at autogpt_platform/backend/backend/api/features/admin/diagnostics_admin_routes.py:408

    ⚠️ WARNING: Only use for stuck executions. This will re-execute and may cost credits.

    Args:
        request: Contains execution_id to requeue

    Returns:
        Success status and message
    """
    logger.info(f"Admin {user.user_id} requeueing execution {request.execution_id}")

    # Get the execution (validation - must be QUEUED)
    executions = await get_graph_executions(
        graph_exec_id=request.execution_id,
        statuses=[AgentExecutionStatus.QUEUED],
    )

    if not executions:
        raise HTTPException(
            status_code=404,
            detail="Execution not found or not in QUEUED status",
        )

    execution = executions[0]

    # Use add_graph_execution in requeue mode. ``bypass_paywall=True``
    # because admins are recovering stuck executions on behalf of users
    # who may now be on NO_TIER — the original run was already gated.
    await add_graph_execution(
        graph_id=execution.graph_id,
        user_id=execution.user_id,
        graph_version=execution.graph_version,
        graph_exec_id=request.execution_id,  # Requeue existing execution
        bypass_paywall=True,
    )

    return RequeueExecutionResponse(

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Re-fetch the execution's current status (admin diagnostics list) and only requeue while it still shows QUEUED.
  2. Verify the execution_id UUID against the AgentGraphExecution table.
  3. If the execution is RUNNING, use the stop endpoint instead; if COMPLETED/FAILED, create a new run.
  4. Retry the requeue once — a transient race with the executor scheduler may clear.
Defensive patterns

Strategy: retry

Validate before calling

const exec = await getExecution(request.executionId);
if (!exec || exec.status !== 'QUEUED') { /* refresh the admin table; don't requeue */ }

Type guard

function isRequeueable(e: { status: string }): boolean { return e.status === 'QUEUED'; }

Try / catch

try { await requeueExecution(executionId); } catch (e) { if (e.status === 404) { const exec = await getExecution(executionId); if (!exec) reportMissing(); else if (exec.status === 'RUNNING') await stopExecution(executionId); /* else already terminal */ } }

Prevention

When it happens

Trigger: POST /admin/execution/requeue with a stale execution_id (already picked up by the executor), a typo'd UUID, or an execution that already completed/failed. Race: the admin checks the list, the executor starts the run, then the requeue request lands and finds no QUEUED row.

Common situations: Recovering executions after a RabbitMQ/executor outage — by the time an admin acts, some listed executions have already started; double-submitting the requeue form; copying the wrong id from the diagnostics table.

Related errors


AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14). Data as JSON: /api/errors/6807fcf590f5af43. Report an issue: GitHub.