Significant-Gravitas/AutoGPT · error · HTTPException

Dream pass scheduling failed: {type(exc).__name__}: {exc}

Error message

Dream pass scheduling failed: {type(exc).__name__}: {exc}

What it means

HTTP 500 raised after an on-demand dream pass was accepted (initial status row already written) but the scheduler client failed to enqueue schedule_immediate_dream_pass. The detail embeds the underlying exception class name and message, and the job's stored status is marked failed via _mark_schedule_failed, so a subsequent status poll shows the failure.

Source

Thrown at autogpt_platform/backend/backend/api/features/admin/memory_admin_routes.py:767

    job_id = str(_uuid.uuid4())
    status = await write_initial_status(
        kind="dream_pass", job_id=job_id, user_id=target
    )

    try:
        await get_scheduler_client().schedule_immediate_dream_pass(
            user_id=target, job_id=job_id
        )
    except Exception as exc:
        logger.warning(
            "Failed to schedule dream pass %s for user %s: %s",
            job_id[:12],
            target[:12],
            exc,
        )
        await _mark_schedule_failed("dream_pass", job_id, exc)
        raise HTTPException(
            status_code=500,
            detail=f"Dream pass scheduling failed: {type(exc).__name__}: {exc}",
        )

    payload = JobTriggerResponse(
        job_id=status.job_id,
        user_id=status.user_id,
        kind=status.kind,
        state=status.state,
        started_at=status.started_at,
    )
    return JSONResponse(status_code=202, content=payload.model_dump(mode="json"))


@router.get(
    "/{user_id}/dream/{job_id}",
    response_model=DreamJobStatus,
)

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Check backend logs for the preceding 'Failed to schedule dream pass' warning — it contains the root exception
  2. Verify the scheduler/broker service is running: docker compose ps, and that the API container can reach it
  3. Compare broker/scheduler connection settings in .env between the API and scheduler processes
  4. GET the job status endpoint for the returned job_id — it will show the failed state and stored error
  5. Retry the POST once infrastructure is healthy; the failed job row is terminal and a new job_id is issued
Defensive patterns

Strategy: try-catch

Validate before calling

# Pre-flight: scheduler reachable (health endpoint if available)
assert await scheduler_healthcheck(), "scheduler down; dream pass will 500"

Try / catch

try:
    resp = await client.post(f"/memory/{uid}/dream")
except httpx.HTTPStatusError as e:
    if e.response.status_code == 500 and "scheduling failed" in e.response.json()["detail"]:
        detail = e.response.json()["detail"]  # contains root exception name
        # job already marked failed; safe to re-trigger after infra fix
        ...
    raise

Prevention

When it happens

Trigger: POST /{user_id}/dream succeeds at validation, but the scheduler backend (queue/broker backing get_scheduler_client) is unreachable, not running, has auth mismatch, or raises any exception during schedule_immediate_dream_pass — e.g. RabbitMQ/Redis/scheduler service down in the docker-compose stack or in a deployment where the scheduler is a separate process.

Common situations: Local dev without the scheduler service started (docker compose up -d skipped or partial); broker connection env vars (host/port/credentials) wrong in .env; scheduler deployed separately and network-partitioned; version skew between API and scheduler after a partial deploy.

Related errors


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