Significant-Gravitas/AutoGPT · error · NotFoundError

Session 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.

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 not found or access denied
• codex_credential_not_found
• Expert not found
• Application not found or you don't have permission to…
• builder_graph_id and expert_id are mutually exclusive

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

Appendix: 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)