Significant-Gravitas/AutoGPT · error · NotFoundError

Session {session_id} not found.

Error message

Session {session_id} not found.

What it means

A NotFoundError (surfaced as 404) from the chat session ownership validator: get_chat_session_metadata(session_id, user_id) returned None, meaning no session with that id exists OR it exists but belongs to a different user/organization. The helper deliberately fetches metadata only (no message history) for cheap ownership checks; None covers both 'missing' and 'not yours' without leaking which.

Source

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

logger = logging.getLogger(__name__)

config = ChatConfig()
credentials_manager = IntegrationCredentialsManager()


async def _validate_and_get_session(
    session_id: str,
    user_id: str | None,
) -> ChatSessionInfo:
    """Validate session exists and belongs to user.

    Returns metadata-only — callers needing the message history must use
    ``get_chat_session`` directly. Bypassing the message-loading path
    avoids a multi-KB cache deserialisation per ownership check.
    """
    session = await get_chat_session_metadata(session_id, user_id)
    if not session:
        raise NotFoundError(f"Session {session_id} not found.")
    return session


# Minimum age before the orphan-reset paths (``get_session`` and
# ``cancel_session_task``) will touch a ``chatStatus='running'`` session
# that has no live Redis stream.  Lower bound has to clear the
# ``acquire_turn_slot``→``dispatch_turn.create_session`` window (a few
# ms in practice).  30s is a generous safety margin — anything still
# at ``running`` after that without a Redis stream is genuinely an
# orphan, not an in-flight admit racing this read.
_ORPHAN_RUNNING_RESET_THRESHOLD_SECONDS = 30


async def _try_release_orphan_running(session_id: str, user_id: str) -> bool:
    """Force-release a session if it's stuck in ``chatStatus='running'``
    older than ``_ORPHAN_RUNNING_RESET_THRESHOLD_SECONDS`` (= the
    ``acquire_turn_slot``→``create_session`` race window).  Returns
    True iff a release happened — callers map that into their response

View on GitHub (pinned to 9c8bb5550f)

Solutions

1. Refresh the client's session list (the id is likely deleted or belongs to another account) and retry with a current id.
2. Verify environment consistency: the session id must come from the same backend/environment the request targets.
3. If it should exist, check in the DB (ChatSession table) whether the row exists and compare its user_id/organization with the authenticated user; a mismatch means an auth-context bug, not a missing session.

const sessions = await listSessions();
if (!sessions.some(s => s.session_id === sessionId)) redirect('/chat');

try {
  await api.getSession(sessionId);
} catch (e) {
  if (e.status === 404) { dropLocalSession(sessionId); navigate('/chat'); return; }
  throw e;
}

When it happens

Trigger: Any chat route that calls _validate_and_get_session — e.g. GET/DELETE/PATCH on /chat/sessions/{session_id} — with a session id that was deleted, never existed, belongs to another user, or was created under a different organization context.

Common situations: Stale session id kept in frontend state after the user deleted the session in another tab; copy-pasting or reusing ids across environments (dev id against prod API); logged-out user with a cached id; session pruned by retention cleanup; wrong user context after an account switch.

Related errors

• Session {session_id} not found or access denied
• codex_credential_not_found
• Expert not found
• Graph #{graph_id} not found.
• Title must not be blank

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