Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Regression since 2026.4.29: Slack-heavy session lists can saturate gateway via sessions.list [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#77062•Fetched 2026-05-05 05:52:53
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
2
Author
leovoloshinleovoloshin
Participants
clawsweeper[bot]clawsweeper[bot]leovoloshinleovoloshin
Timeline (top)
referenced ×2closed ×1commented ×1cross-referenced ×1

On a long-lived Slack-heavy OpenClaw install, sessions.list / dashboard session loading became a gateway-wide bottleneck after upgrading to 2026.4.29. I did not see this before 2026.4.29. The same behavior still reproduced immediately after updating to 2026.5.2.

When the issue is active, session/dashboard RPCs can pin the gateway process around one CPU core and make sessions.list take tens of seconds. This is not only a slow Control UI problem: Slack responsiveness degrades because Slack Socket Mode / channel handling shares the same saturated gateway process.

Root Cause

When the issue is active, session/dashboard RPCs can pin the gateway process around one CPU core and make sessions.list take tens of seconds. This is not only a slow Control UI problem: Slack responsiveness degrades because Slack Socket Mode / channel handling shares the same saturated gateway process.

Fix Action

Fix / Workaround

After updating from 2026.4.29 to 2026.5.2, the plain unpatched 2026.5.2 gateway reproduced the same dashboard/gateway starvation pattern:

Local Mitigation That Restored Usability

I applied a local installed-bundle hotfix that made the session-listing path cheaper. Usability improved after:

PR fix notes

PR #77123: [codex] fix(gateway): bound sessions list responses

Description (problem / solution / changelog)

Summary

This bounds the default Gateway sessions.list response so callers that omit limit no longer force the Gateway to build every matching session row in one request.

Changes:

  • apply a default 100-row cap to listSessionsFromStore / listSessionsFromStoreAsync
  • return totalCount, limitApplied, and hasMore metadata so clients can show when more rows exist
  • keep internal session resolution unbounded where full-store semantics are required
  • document the bounded RPC behavior and add regression coverage for default and explicit limits

Fixes #77062.

Why

#77062 reports Slack-heavy, long-lived installs where sessions.list / dashboard loading could take tens of seconds and saturate the shared Gateway process. Recent main already made row construction lighter, but the bare RPC path still treated an omitted limit as unbounded.

That left any caller using plain sessions.list able to enumerate and enrich every selected row, which is the failure class behind the Slack Socket Mode degradation: expensive dashboard/session work can monopolize the same event loop that channel transports depend on.

Behavior Change

Callers that need a larger window can still pass an explicit positive limit. Default calls now receive the newest 100 matching rows plus metadata indicating whether more rows exist:

  • count: number of rows returned
  • totalCount: number of matching rows before the cap
  • limitApplied: effective row limit
  • hasMore: whether the response was truncated

This intentionally does not add pagination yet; it establishes the safety bound and response shape needed for follow-up UI/API pagination work.

Verification

  • pnpm test src/gateway/session-utils.test.ts src/gateway/server.sessions.list-changed.test.ts
  • pnpm exec oxfmt --check --threads=1 src/shared/session-types.ts src/gateway/session-utils.ts src/gateway/session-utils.test.ts src/gateway/protocol/schema/sessions.ts src/tui/tui-backend.ts docs/cli/sessions.md CHANGELOG.md
  • pnpm exec oxlint --deny-warnings src/shared/session-types.ts src/gateway/session-utils.ts src/gateway/session-utils.test.ts src/gateway/protocol/schema/sessions.ts src/tui/tui-backend.ts
  • git diff --check
  • Testbox pnpm check:changed on tbx_01kqrq3nn2v7qb4bwrsmw37g5h, run https://github.com/openclaw/openclaw/actions/runs/25302557993
  • Clean rebase onto current origin/main; rebase sanity: git status, git diff --check, and unchanged diff stat

Current PR head: 9213fbd3105372dc1e3275b1e760606e1cd1c918.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • docs/cli/sessions.md (modified, +6/-0)
  • src/gateway/protocol/schema/sessions.ts (modified, +4/-0)
  • src/gateway/session-utils.test.ts (modified, +58/-0)
  • src/gateway/session-utils.ts (modified, +49/-6)
  • src/shared/session-types.ts (modified, +3/-0)
  • src/tui/tui-backend.ts (modified, +3/-0)
RAW_BUFFERClick to expand / collapse

Summary

On a long-lived Slack-heavy OpenClaw install, sessions.list / dashboard session loading became a gateway-wide bottleneck after upgrading to 2026.4.29. I did not see this before 2026.4.29. The same behavior still reproduced immediately after updating to 2026.5.2.

When the issue is active, session/dashboard RPCs can pin the gateway process around one CPU core and make sessions.list take tens of seconds. This is not only a slow Control UI problem: Slack responsiveness degrades because Slack Socket Mode / channel handling shares the same saturated gateway process.

Environment

  • OpenClaw versions affected: observed after 2026.4.29; still reproduced on 2026.5.2
  • Platform: macOS
  • Install shape: long-lived local gateway
  • Channels: Slack enabled and heavily used; Telegram also enabled
  • Control UI/dashboard: enabled
  • Session profile: many Slack-originated sessions accumulated over time

Observed Behavior

After updating from 2026.4.29 to 2026.5.2, the plain unpatched 2026.5.2 gateway reproduced the same dashboard/gateway starvation pattern:

  • sessions.list calls took roughly 36-66s
  • openclaw status --deep could wedge or time out against the gateway even though the service was running
  • the gateway process pinned roughly one CPU core while this was happening
  • Slack became unreliable/degraded while the gateway was saturated

This felt like a regression that first cropped up around 2026.4.29, not merely an old long-lived-session problem that had always existed.

Why This Seems Distinct From Existing Trackers

This may be related to #47975 and #71631, but it does not look like only a generic "completed subagent sessions are retained" issue.

The user-visible failure mode here is:

Slack-heavy install with many sessions -> sessions.list/dashboard work gets very expensive -> gateway event loop/CPU saturates -> Slack responsiveness and Socket Mode reliability degrade.

That makes this a gateway isolation and bounded-listing problem, not just a dashboard UX issue.

Local Mitigation That Restored Usability

I applied a local installed-bundle hotfix that made the session-listing path cheaper. Usability improved after:

  • capping sessions.list rows to a small default
  • disabling expensive derived-title / last-message preview work by default
  • skipping model catalog work inside sessions.list
  • disabling transcript usage fallback work during session-list row construction

After that, sessions.list returned in a few seconds instead of tens of seconds, and gateway CPU returned to normal idle behavior.

I am not proposing that exact patch as the right fix, but it strongly suggests the expensive enrichment/listing path is enough to starve the gateway on a Slack-heavy install.

Expected Behavior

  • sessions.list should be bounded, paginated, cached, or otherwise cheap by default.
  • Expensive transcript/model/preview enrichment should be opt-in, async, cached, or isolated from the hot path.
  • Control UI/dashboard session loading should not be able to degrade Slack Socket Mode/channel responsiveness.
  • A long-lived Slack install with many sessions should not require manual pruning or local bundle patches to keep the gateway responsive.

Related Issues

  • #47975: broader session/subagent retention and visibility contract
  • #71631: broader Control UI/gateway responsiveness umbrella
  • #64004: related Control UI latency attribution work
  • #58534 / #59317: older session accumulation / polling evidence

extent analysis

TL;DR

Capping sessions.list rows and disabling expensive derived-title/last-message preview work may help mitigate the gateway saturation issue on Slack-heavy OpenClaw installs.

Guidance

  • Investigate the expensive session-listing path and consider implementing pagination, caching, or async processing to reduce the load on the gateway.
  • Review the local mitigation hotfix applied by the user, which capped sessions.list rows and disabled expensive derived-title/last-message preview work, to understand the potential impact on performance.
  • Consider implementing opt-in, async, or cached enrichment for transcript/model/preview data to prevent degradation of Slack Socket Mode/channel responsiveness.
  • Monitor the gateway's CPU usage and session loading times to identify potential bottlenecks and areas for optimization.

Example

No specific code snippet is provided, but the local mitigation hotfix suggests that modifying the sessions.list implementation to cap rows and disable expensive work may be a viable workaround.

Notes

The issue appears to be related to the expensive session-listing path and the accumulation of many Slack-originated sessions over time. The local mitigation hotfix provides a potential starting point for addressing the issue, but further investigation and optimization may be necessary to fully resolve the problem.

Recommendation

Apply a workaround by capping sessions.list rows and disabling expensive derived-title/last-message preview work, as this has been shown to improve usability and reduce gateway CPU saturation in the short term.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#file not found#serialization error#model compatibility#GPU setup#container setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Regression since 2026.4.29: Slack-heavy session lists can saturate gateway via sessions.list [1 pull requests, 1 comments, 2 participants]