Significant-Gravitas/AutoGPT · critical · HTTPException

Chat read path unhealthy: session not found after create

Error message

Chat read path unhealthy: session not found after create

What it means

HTTP 503 from the chat health-check endpoint (routes.py:1986). The probe creates a synthetic user and a real chat session (dry_run=False), then reads it back via get_chat_session_metadata. If the freshly created session cannot be found, the read path is declared unhealthy and the endpoint returns 503 'Chat read path unhealthy: session not found after create'.

Source

Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:1986

    """
    from backend.data.user import get_or_create_user

    # Ensure health check user exists (required for FK constraint)
    health_check_user_id = "health-check-user"
    await get_or_create_user(
        {
            "sub": health_check_user_id,
            "email": "health-check@system.local",
            "user_metadata": {"name": "Health Check User"},
        }
    )

    # Create and retrieve session to verify full data layer
    session = await create_chat_session(health_check_user_id, dry_run=False)
    fetched = await get_chat_session_metadata(session.session_id, health_check_user_id)
    if fetched is None:
        raise HTTPException(
            status_code=503,
            detail="Chat read path unhealthy: session not found after create",
        )

    return {
        "status": "healthy",
        "service": "chat",
        "version": "0.1.0",
    }


# ========== Schema Export (for OpenAPI / Orval codegen) ==========

ToolResponseUnion = (
    AgentsFoundResponse
    | NoResultsResponse
    | AgentDetailsResponse
    | SetupRequirementsResponse

View on GitHub (pinned to 9c8bb5550f)

Solutions

1. Check Postgres health and the backend DB connection (Prisma logs, DATABASE_URL) — the write succeeded but the read didn't.
2. If using read replicas, verify replication lag and that the health check reads from the primary.
3. Ops: this failing means the load balancer should pull the instance; investigate the DB before user-facing debugging.
4. Rule out test-env flakiness where the health-check user/session fixtures collide.

try { await get('/chat/health'); } catch (e) {
  if (e.status === 503) { markInstanceUnhealthy(); pageOut(); alertOps('chat DB read path broken'); return; }
  throw e;
}

When it happens

Trigger: Hitting the chat health check while the database (Prisma/Postgres) is failing reads, in a split-brain state, or when the create committed to a different store than the read (e.g. read replica lag or misrouted connections).

Common situations: Load balancer health probes going red during DB incidents; Postgres restart/failover; replica lag after a burst of writes; a misconfigured DATABASE_URL pointing writes and reads at different instances.

Related errors

• Unable to verify reset eligibility — please try again later.
• Rate limit reset failed — please try again later. Your credi
• Chat service degraded, retry shortly
• Rate limit service degraded, retry shortly
• Rate limit reset is not available.

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