openclaw - 💡(How to fix) Fix Performance: Session list queries trigger full materialization + synchronous transcript reads [1 participants]

Summary

Session list and lookup queries currently materialize all session rows (including synchronous transcript reads) before applying search, filter, and limit. This causes query latency to grow linearly with the total number of sessions.

Reproduction

Tested on [email protected] with 387 sessions in agents/main/sessions/sessions.json.

Issue 1: Full materialization before pagination

In session-utils (buildGatewaySessionRow), every session entry triggers:

• resolveTranscriptUsageFallback() → reads the full transcript file to extract token usage
• readSessionTitleFieldsFromTranscript() → reads the full transcript file to extract derived title and last message preview

These happen for all entries before search and limit are applied:

// session-utils L890-899
const sessions = filteredEntries
  .map(([key, entry]) => buildGatewaySessionRow({ cfg, key, entry, ...params }))
  .toSorted((a, b) => (b.updatedAt ?? 0) - (a.updatedAt ?? 0));
// search/limit applied AFTER full materialization

The transcript reads use synchronous I/O (readFileSync), blocking the event loop:

// session-utils.fs L491
const content = fs.readFileSync(fd, "utf-8");

Issue 2: Single session lookup uses full list scan

In sessions-resolve L53-55:

const entry = Object.entries(store).find(
  ([key, entry]) => entry?.sessionId === sessionId
);

And in gateway-cli, the pattern is:

const matches = listSessionsFromStore(...).sessions
  .filter((session) => session.sessionId === sessionId || session.key === sessionId);

This means looking up a single session by ID still triggers materialization of all sessions.

Issue 3: MCP getConversation uses limit: 500 list reuse

In mcp-cli L179-185:

async getConversation(sessionKey) {
    return (await this.listConversations({
        limit: 500,
        includeLastMessage: true
    })).find((conversation) => conversation.sessionKey === normalizedSessionKey) ?? null;
}

listConversations defaults to includeDerivedTitles: true and includeLastMessage: true, so each of the 500 sessions triggers transcript reads just to find one specific session.

Impact

• Session list page latency grows linearly with total session count
• Single-session lookups pay the cost of scanning all sessions
• Synchronous readFileSync blocks the Node.js event loop during queries
• With 387 sessions, this is already noticeable; at 1000+ it would be significantly worse

Suggested Fix

Introduce a lightweight SessionSummaryIndex that:

1. Pre-computes summary fields at write time (title, lastMessage preview, token usage) rather than reading transcripts at query time
2. Applies filter/search/limit on summaries first, then hydrates only the current page from transcripts if needed
3. Provides direct lookup by sessionId without scanning all sessions
4. Changes getConversation to use direct lookup instead of listConversations(limit: 500)

Workaround

Pre-populating totalTokens, inputTokens, outputTokens, cacheRead, cacheWrite, and estimatedCostUsd into sessions.json entries allows buildGatewaySessionRow to skip resolveTranscriptUsageFallback, reducing transcript reads. However, this does not help with readSessionTitleFieldsFromTranscript or the architectural issues (full scan before limit, getConversation with limit:500).