Skip to content

Telegram forum topic session continuity breaks after gateway restart (OOM-kill): new sessionFile created, prior history not loaded #21850

@openclaw-quenio

Description

@openclaw-quenio

Summary

When using Telegram forum topics (threaded chats), OpenClaw sometimes starts a new local session for the same topic after a gateway restart (observed after repeated systemd OOM-kill restarts). The new session then has no prior history injected (provider inbound context shows history_count: 0), even though OpenClaw still has a previous session file for that exact topic on disk.

This makes it look like “topic thread history got wiped overnight”.

Environment

  • OpenClaw CLI: 2026.2.13
  • Gateway service: systemd user service (openclaw-gateway.service)
  • OS: Linux
  • Channel: Telegram
  • Chat type: Telegram forum (topics/threads)

Observed behavior

  • Telegram forum topic (threadId 2731) had an existing local session file:
    • ~/.openclaw/agents/main/sessions/fd5bf3e1-b766-46c3-a9aa-3c0c748f5b65-topic-2731.jsonl
    • begins at 2026-02-20T00:26:23Z and contains user+assistant messages.
  • After gateway restarts (OOM-kill), a later message in the same Telegram topic created a new session:
    • ~/.openclaw/agents/main/sessions/9ea2109d-3077-4c85-b6e3-85db6444a2bb-topic-2731.jsonl
    • begins at 2026-02-20T12:42:17Z
  • sessions.json now indexes the topic key to the newer session file:
{
  "key": "agent:main:telegram:group:-1003515510780:topic:2731",
  "sessionId": "9ea2109d-3077-4c85-b6e3-85db6444a2bb",
  "sessionFile": "/home/openclaw/.openclaw/agents/main/sessions/9ea2109d-3077-4c85-b6e3-85db6444a2bb-topic-2731.jsonl",
  "groupId": "-1003515510780:topic:2731",
  "lastThreadId": 2731
}

Result: the agent sees no earlier messages for that topic (and asks the user to paste history), despite the earlier topic session file still being present.

Evidence: session file starts

Older session file start:

{"type":"session","id":"fd5bf3e1-b766-46c3-a9aa-3c0c748f5b65","timestamp":"2026-02-20T00:26:23.534Z"}
{"type":"message", ... "timestamp":"2026-02-20T00:26:23.544Z", "message":{"role":"user", ...}}

Newer session file start:

{"type":"session","id":"9ea2109d-3077-4c85-b6e3-85db6444a2bb","timestamp":"2026-02-20T12:42:17.166Z"}
{"type":"message", ... "timestamp":"2026-02-20T12:42:17.181Z", "message":{"role":"user", ...}}

Evidence: gateway was OOM-killed repeatedly

From journalctl --user -u openclaw-gateway:

... openclaw-gateway.service: Failed with result 'oom-kill'.
... openclaw-gateway.service: Main process exited, code=killed, status=9/KILL

Steps to reproduce (likely)

  1. Use Telegram forum topic, exchange messages (topic session gets written to ...-topic-<id>.jsonl).
  2. Restart gateway (esp. non-gracefully; in this environment it’s via OOM-kill + systemd restart).
  3. Send a new message in the same Telegram topic.
  4. Observe a new sessionId/sessionFile gets created and indexed for the same topic key, and prior topic history is not injected.

Expected

Even after a restart (including unclean shutdown), OpenClaw should:

  • continue appending to the existing session for that topic key, OR
  • recover the prior session by re-linking the topic key to the latest known sessionFile for that topic/thread, OR
  • otherwise merge/rehydrate enough history so the agent doesn’t appear to “forget the thread”.

Actual

A new sessionId/sessionFile is created for the same topic, and the agent sees no prior history.

Notes / hypothesis

This may be caused by how sessions.json is persisted/updated on shutdown/restart, or how topic sessions are resolved when the store has existing topic files but the index doesn’t point to them.

Happy to provide more logs, but wanted to file the core symptom + evidence first.

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleMarked as stale due to inactivity

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions