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
- Check backend logs for the preceding 'Failed to schedule dream pass' warning — it contains the root exception
- Verify the scheduler/broker service is running: docker compose ps, and that the API container can reach it
- Compare broker/scheduler connection settings in .env between the API and scheduler processes
- GET the job status endpoint for the returned job_id — it will show the failed state and stored error
- 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
- Keep scheduler and broker services running before triggering jobs
- Monitor for the 'Failed to schedule dream pass' log warning as an early signal
- Treat 500-on-trigger as infrastructure, not application, failure — fix the broker first
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
- Nightly batch scheduling failed: {type(exc).__name__}: {exc}
- Community rebuild scheduling failed: {type(exc).__name__}: {
- Ratification pass failed: {type(exc).__name__}: {exc}
- str(e)
- OpenAI API key not configured
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/b994c047c6663c5a.
Report an issue: GitHub.