t8y2/dbx · error

agent session not found: {id}

Error message

agent session not found: {id}

What it means

Thrown by the session lookup helper in the TDengine agent driver's runtime when `session(id)` is called with an id that has no entry in the in-memory sessions map. Sessions only exist after `create_session`/registration inserts them, and `close_session` removes them, so lookups of closed or never-created ids fail. The message includes the offending id to make debugging straightforward.

Source

Thrown at agents/drivers/tdengine/src/runtime.rs:257

            .map_err(|_| anyhow!("agent session limit reached: {MAX_AGENT_SESSIONS}"))?;
        let mut driver = TdengineDriver::new();
        driver.connect(params).await?;
        let session = Arc::new(AgentSession {
            driver: Mutex::new(driver),
            active: StdMutex::new(None),
            next_operation_id: AtomicU64::new(1),
            _slot: slot,
        });
        let mut sessions = self.sessions.write().await;
        if sessions.contains_key(id) {
            bail!("agent session already exists: {id}");
        }
        sessions.insert(id.to_string(), session);
        Ok(())
    }

    async fn session(&self, id: &str) -> Result<Arc<AgentSession>> {
        self.sessions.read().await.get(id).cloned().ok_or_else(|| anyhow!("agent session not found: {id}"))
    }

    async fn close_session(&self, id: &str) -> Result<()> {
        let session = self.sessions.write().await.remove(id);
        let Some(session) = session else {
            return Ok(());
        };
        session.cancel();
        session.driver.lock().await.disconnect().await;
        Ok(())
    }

    async fn close_all_sessions(&self) {
        let sessions = {
            let mut sessions = self.sessions.write().await;
            std::mem::take(&mut *sessions)
        };
        for (_, session) in sessions {

View on GitHub (pinned to c0390bff16)

Solutions

  1. Verify the session id passed to the API matches one returned by the session-creation call.
  2. Recreate the session via the create-session API before retrying the operation.
  3. Ensure `close_session` is not called while other tasks still reference the session id.
  4. If ids must survive restarts, add an external session store instead of relying on in-memory state.

Example fix

// before
let session = runtime.session("sess-123").await?; // may be stale
// after
let session = match runtime.session("sess-123").await {
    Ok(s) => s,
    Err(_) => runtime.create_session(params).await?, // recreate and use new id
};
Defensive patterns

Strategy: try-catch

Validate before calling

async fn session_exists(runtime: &dyn AgentRuntime, id: &str) -> bool {
    !id.trim().is_empty() && runtime.session(id).await.is_ok()
}

Try / catch

match runtime.session(id).await {
    Ok(session) => use_session(session).await,
    Err(e) if e.to_string().starts_with("agent session not found") => {
        let session = runtime.create_session(default_params()).await?;
        use_session(session).await
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Calling an agent-runtime method that resolves a session by id when: (1) the id was never created via the session creation path, (2) `close_session(id)` already removed it, (3) the caller passes a stale or typo'd id, or (4) the process restarted and in-memory sessions were lost.

Common situations: Reusing a cached session handle after closing the session; sharing ids between processes (sessions are in-memory, not persisted); race conditions where one task closes a session while another still uses it; service restart dropping all session state while clients still hold old ids.

Related errors

AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05). Data as JSON: /api/errors/c73cecf7fbd9e92d. Report an issue: GitHub.