Significant-Gravitas/AutoGPT · error · HTTPException

Block #{block_id} is disabled.

Error message

Block #{block_id} is disabled.

What it means

Raised (HTTP 403) by the external execute-block endpoint when the requested block exists but its `disabled` flag is set. Disabled blocks are registered but barred from execution platform-wide (e.g. deprecation, security hold, or operator opt-out), so the request is refused before any charging or execution.

Source

Thrown at autogpt_platform/backend/backend/api/external/v1/routes.py:106

async def execute_graph_block(
    block_id: str,
    data: BlockInput,
    auth: APIAuthorizationInfo = Security(
        require_permission(APIKeyPermission.EXECUTE_BLOCK)
    ),
) -> CompletedBlockOutput:
    # Sync block exec doesn't pass through ``add_graph_execution`` (no
    # central enqueue), and external API routes use API-key auth instead
    # of JWT so the JWT-based dep doesn't apply either. Inline strict
    # gate with the same fail-closed (503-on-blip) posture as the dep —
    # consistent with chat / internal block / internal graph routes.
    await enforce_payment_paywall(auth.user_id)

    obj = backend.blocks.get_block(block_id)
    if not obj:
        raise HTTPException(status_code=404, detail=f"Block #{block_id} not found.")
    if obj.disabled:
        raise HTTPException(status_code=403, detail=f"Block #{block_id} is disabled.")

    user = await user_db.get_user_by_id(auth.user_id)
    if not user:
        raise HTTPException(status_code=404, detail="User not found.")

    try:
        await charge_for_direct_block_execution(
            user_id=auth.user_id, block=obj, input_data=data, source="external"
        )
    except InsufficientBalanceError as e:
        raise HTTPException(
            status_code=status.HTTP_402_PAYMENT_REQUIRED, detail=str(e)
        ) from e

    # Direct block execution has no graph; build a minimal ExecutionContext
    # carrying the caller's identity + timezone so blocks that depend on
    # those (e.g. time blocks) get correct data.
    execution_context = ExecutionContext(

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Check the block catalog for an enabled replacement block and migrate inputs to its schema.
  2. If you operate the platform and need the block, flip its `disabled` flag in code/config and redeploy.
  3. Pin your automation to block versions/ids validated for `disabled == false` before executing.
Defensive patterns

Strategy: validation

Validate before calling

blocks = {b["id"]: b for b in client.get("/blocks").json()}
b = blocks.get(block_id)
if b is None:
    raise UnknownBlock(block_id)
if b.get("disabled"):
    replacement = find_replacement(blocks, b)  # same category, enabled
    raise BlockDisabled(f"use {replacement['id']} instead")

Try / catch

try:
    client.post(f"/blocks/{block_id}/execute", json=data)
except HTTPError as e:
    if e.response.status_code == 403 and "disabled" in e.response.text:
        raise BlockDisabled(block_id)  # pick an enabled replacement from catalog
    raise

Prevention

When it happens

Trigger: POST `/blocks/{block_id}/execute` for a block whose `disabled=True` in the registry — typically a deprecated block or one disabled by the platform operators.

Common situations: A block was deprecated in a newer release while old graphs/scripts still reference it; operators disable a block due to a vulnerability; beta blocks disabled by default in some deployments.

Related errors


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