Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bug: "Communications", "AI & Agents", and "Automation" Menus Extremely Slow / Freezing the Control UI (Related to #45698) [5 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#77060•Fetched 2026-05-05 05:52:54
View on GitHub
Comments
1
Participants
2
Timeline
10
Reactions
2
Author
wangjianjqwangjianjq
Participants
clawsweeper[bot]clawsweeper[bot]wangjianjqwangjianjq
Timeline (top)
cross-referenced ×5labeled ×2commented ×1referenced ×1

The "Communications", "AI & Agents", and "Automation" menus in the OpenClaw dashboard-v2 are extremely slow, often freezing the UI for 10-15 seconds. This is directly related to Issue #45698 and is caused by blocking health probes (getMe) for Telegram and heavy config schema rendering on the frontend.

Root Cause

The "Communications", "AI & Agents", and "Automation" menus in the OpenClaw dashboard-v2 are extremely slow, often freezing the UI for 10-15 seconds. This is directly related to Issue #45698 and is caused by blocking health probes (getMe) for Telegram and heavy config schema rendering on the frontend.

Fix Action

Fix / Workaround

Workarounds identified:

  1. Set channels.telegram.healthMonitor.enabled = false to disable the blocking getMe probe.
    1. Use NODE_OPTIONS=--dns-result-order=ipv4first to bypass IPv6 blackhole issues that trigger the 10s timeout. Architecture Recommendations:
  3. Decouple health probes from the main request flow (make them non-blocking).
    1. Expose httpTimeoutMs for Telegram channels (similar to Feishu) to allow user-defined timeouts.
    1. Optimize dashboard-v2 frontend rendering for large config schemas.

PR fix notes

PR #2: fix(telegram): add httpTimeoutMs config for health probe timeout control

Description (problem / solution / changelog)

Summary

Expose httpTimeoutMs in Telegram network config (similar to Feishu implementation) to allow users to reduce the probe timeout for faster fail-fast when Telegram is unreachable due to IPv6 issues or high latency.

Problem

When Telegram health probe (getMe) encounters IPv6 blackhole issues or high latency, it can block the gateway event loop for 10-15 seconds, causing dashboard menus to freeze. This is a regression that affects all users with Telegram health monitoring enabled.

Solution

Added httpTimeoutMs option to channels.telegram.network config:

channels:
  telegram:
    network:
      # Set to 5000ms for faster fail-fast (default: 15000ms)
      httpTimeoutMs: 5000

When configured, this limits each HTTP request in the probe to the specified timeout instead of the full probe budget. This allows probes to fail quickly when Telegram is unreachable, preventing gateway event loop blocking.

Changes

  1. Type definition (src/config/types.telegram.ts): Added httpTimeoutMs?: number to TelegramNetworkConfig
  2. Zod schema (src/config/zod-schema.providers-core.ts): Added validation for httpTimeoutMs (positive integer, max 60000ms)
  3. Probe implementation (extensions/telegram/src/probe.ts): Modified to use httpTimeoutMs from network config for per-request timeout
  4. Tests (extensions/telegram/src/probe.test.ts): Added two tests for httpTimeoutMs behavior

Fixes

Fixes #77060

Changed files

  • CHANGELOG.md (modified, +2/-0)
  • extensions/google-meet/index.test.ts (modified, +19/-7)
  • extensions/google-meet/openclaw.plugin.json (modified, +9/-0)
  • extensions/qa-lab/src/mantis/desktop-browser-smoke.runtime.test.ts (modified, +58/-0)
  • extensions/qa-lab/src/mantis/desktop-browser-smoke.runtime.ts (modified, +2/-2)
  • extensions/qa-lab/src/mantis/slack-desktop-smoke.runtime.test.ts (modified, +63/-0)
  • extensions/qa-lab/src/mantis/slack-desktop-smoke.runtime.ts (modified, +2/-2)
  • extensions/telegram/src/probe.test.ts (modified, +72/-0)
  • extensions/telegram/src/probe.ts (modified, +11/-2)
  • src/config/sessions/transcript-append.ts (modified, +29/-2)
  • src/config/types.telegram.ts (modified, +8/-0)
  • src/config/zod-schema.providers-core.ts (modified, +9/-0)
  • src/context-engine/registry.ts (modified, +43/-0)
  • src/plugins/loader.ts (modified, +8/-0)
  • ui/src/styles/chat/tool-cards.css (modified, +1/-1)
  • ui/src/ui/chat/tool-cards.test.ts (modified, +42/-1)
  • ui/src/ui/chat/tool-cards.ts (modified, +18/-0)

PR #77076: fix(webchat): render read tool output and fix exec output overflow + migrateLinearTranscript idempotent

Description (problem / solution / changelog)

Summary

This PR contains two fixes:

Fix 1: WebChat session transcript overwritten every turn (fixes #77012)

Makes migrateLinearTranscriptToParentLinked idempotent by collecting existing IDs before processing.

Fix 2: Control UI webchat tool output issues (fixes #77054)

Bug 1 - read tool output not rendered:

  • extractToolText() in tool-cards.ts only handled item.text and item.content as strings
  • Modern tool results have item.content as array: [{ type: 'text', text: '...' }]
  • Added array content block handling to extract text from nested blocks

Bug 2 - exec output text clipped:

  • .chat-tool-card had overflow:hidden which clipped long content when max-height exceeded
  • Changed to overflow:auto to allow scrolling

Files Changed

  • ui/src/ui/chat/tool-cards.ts - extractToolText array handling
  • ui/src/styles/chat/tool-cards.css - overflow:hidden to overflow:auto
  • ui/src/ui/chat/tool-cards.test.ts - new tests

Changed files

  • extensions/telegram/src/probe.test.ts (modified, +72/-0)
  • extensions/telegram/src/probe.ts (modified, +11/-2)
  • src/config/sessions/transcript-append.ts (modified, +29/-2)
  • src/config/types.telegram.ts (modified, +8/-0)
  • src/config/zod-schema.providers-core.ts (modified, +9/-0)
  • src/context-engine/registry.ts (modified, +43/-0)
  • src/plugins/loader.ts (modified, +8/-0)
  • ui/src/styles/chat/tool-cards.css (modified, +1/-1)
  • ui/src/ui/chat/tool-cards.test.ts (modified, +42/-1)
  • ui/src/ui/chat/tool-cards.ts (modified, +18/-0)

PR #77091: fix(telegram): add httpTimeoutMs config for health probe timeout control (fixes #77060)

Description (problem / solution / changelog)

Fixes #77060 - Control UI menus freezing due to Telegram blocking health probe

Changed files

  • extensions/telegram/src/probe.test.ts (modified, +72/-0)
  • extensions/telegram/src/probe.ts (modified, +11/-2)
  • src/config/sessions/transcript-append.ts (modified, +29/-2)
  • src/config/types.telegram.ts (modified, +8/-0)
  • src/config/zod-schema.providers-core.ts (modified, +9/-0)
  • src/context-engine/registry.ts (modified, +43/-0)
  • src/plugins/loader.ts (modified, +8/-0)
  • ui/src/styles/chat/tool-cards.css (modified, +1/-1)
  • ui/src/ui/chat/tool-cards.test.ts (modified, +42/-1)
  • ui/src/ui/chat/tool-cards.ts (modified, +18/-0)

PR #77092: fix: persist and restore registered context engines in plugin cache (fixes #77063)

Description (problem / solution / changelog)

Fixes #77063 - lossless-claw selected and enabled but not registered as context engine

Root cause: When a cached plugin registry is reused, context engines registered by plugins (like lossless-claw) are lost because the cached state restoration did not restore registered context engines.

Changes:

  • src/context-engine/registry.ts: Add RegisteredContextEngineEntry type, listRegisteredContextEngines(), and restoreRegisteredContextEngines() functions
  • src/plugins/loader.ts: Add contextEngines field to CachedPluginState, restore context engines when using cached state, and save contextEngines to cache

Changed files

  • extensions/telegram/src/probe.test.ts (modified, +72/-0)
  • extensions/telegram/src/probe.ts (modified, +11/-2)
  • src/config/sessions/transcript-append.ts (modified, +29/-2)
  • src/config/types.telegram.ts (modified, +8/-0)
  • src/config/zod-schema.providers-core.ts (modified, +9/-0)
  • src/context-engine/registry.ts (modified, +43/-0)
  • src/plugins/loader.ts (modified, +8/-0)
  • ui/src/styles/chat/tool-cards.css (modified, +1/-1)
  • ui/src/ui/chat/tool-cards.test.ts (modified, +42/-1)
  • ui/src/ui/chat/tool-cards.ts (modified, +18/-0)

PR #77065: fix(plugins): preserve corpus supplements from service.start() during activating re-loads

Description (problem / solution / changelog)

Summary

  • Corpus supplements registered from a plugin's service.start() callback were silently wiped when loadOpenClawPlugins ran with shouldActivate=true on a subsequent call (e.g. lazy memory_search tool load re-trigger)
  • clearActivatedPluginRuntimeState() wipes all supplements at the start of every activating load; since registerService is idempotent, service.start() is never re-called, so supplements from it are permanently lost
  • Fix: capture preLoadCorpusSupplements before clearing; after the registration loop, restore any supplement whose plugin did not re-register via register() in the new pass

Root cause (verified by source trace)

loader.ts:1505 — clearActivatedPluginRuntimeState() → clearMemoryPluginState() wipes supplements. registry.ts:1403 — registerService returns early (idempotent guard) if same service ID was already registered; service.start() not called again. Result: supplement lost with no error.

Test plan

  • New regression test: preserves corpus supplements registered from service.start() during activating re-loads (#77039) — verifies a pre-load supplement survives a full activating reload where the plugin's register() does not call registerMemoryCorpusSupplement
  • pnpm exec vitest run src/plugins/loader.test.ts — 124/124 pass
  • pnpm exec vitest run src/plugins/loader*.test.ts — 177/177 pass
  • pnpm exec tsc --noEmit --project tsconfig.core.json — no new errors
  • pnpm exec oxlint src/plugins/loader.ts src/plugins/loader.test.ts — clean
  • pnpm exec oxfmt --threads=1 src/plugins/loader.ts src/plugins/loader.test.ts — formatted

Fixes #77039.

🤖 Generated with Claude Code

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/plugins/loader.test.ts (modified, +144/-0)
  • src/plugins/loader.ts (modified, +22/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

The "Communications", "AI & Agents", and "Automation" menus in the OpenClaw dashboard-v2 are extremely slow, often freezing the UI for 10-15 seconds. This is directly related to Issue #45698 and is caused by blocking health probes (getMe) for Telegram and heavy config schema rendering on the frontend.

Steps to reproduce

  1. Open OpenClaw dashboard-v2.
    1. Click on the "Communications", "AI & Agents", or "Automation" menu.
    1. Observe the browser UI freezing for 10-15 seconds before the page content finally appears.
    1. Verify in gateway logs that the Telegram health probe (getMe) timed out due to an IPv6 blackhole or high latency.

Expected behavior

The dashboard menus should load asynchronously and remain responsive. A delay or timeout in a specific backend channel (e.g., Telegram API) should not block the entire gateway's event loop or freeze the user interface.

Actual behavior

A blocking health probe (getMe) for Telegram triggers a 10s timeout, stalling the entire gateway's main event loop. Concurrent WebSocket requests (models.list, sessions.list, etc.) are forced to wait. After the data is finally returned, the dashboard-v2 frontend freezes for another 3-5s while attempting to render a 120KB configuration payload combined with a large schema.

OpenClaw version

2026.5.2

Operating system

Linux (Docker)

Install method

docker

Model

any (e.g. minimax/text-01)

Provider / routing chain

openclaw -> telegram (blocking health probe)

Additional provider/model setup details

The issue is specifically triggered by the Telegram channel health monitor. When 'healthMonitor.enabled' is true, the 'getMe' probe blocks the gateway's event loop for 10 seconds (hardcoded timeout). This stalls all other concurrent WebSocket requests.

Architecture Recommendations:

  1. Make health probes asynchronous/non-blocking so they don't stall the main event loop.
    1. Expose 'httpTimeoutMs' for Telegram channels (similar to the Feishu implementation).
    1. Optimize dashboard-v2 form rendering for large configuration schemas to prevent UI freezing.

Logs, screenshots, and evidence

Impact and severity

Affected: All users using Telegram channel with health monitoring enabled. Severity: High (Makes dashboard unusable). Frequency: Always when accessing specific menus (Communications, AI & Agents, Automation). Consequence: 10-15s UI freeze and gateway-wide main loop blocking.

Additional information

Workarounds identified:

  1. Set channels.telegram.healthMonitor.enabled = false to disable the blocking getMe probe.
    1. Use NODE_OPTIONS=--dns-result-order=ipv4first to bypass IPv6 blackhole issues that trigger the 10s timeout. Architecture Recommendations:
  3. Decouple health probes from the main request flow (make them non-blocking).
    1. Expose httpTimeoutMs for Telegram channels (similar to Feishu) to allow user-defined timeouts.
    1. Optimize dashboard-v2 frontend rendering for large config schemas.

extent analysis

TL;DR

Disable the Telegram health monitor or use NODE_OPTIONS=--dns-result-order=ipv4first to mitigate the UI freeze and gateway blocking issue.

Guidance

  • Identify and disable the Telegram health monitor by setting channels.telegram.healthMonitor.enabled to false to prevent the blocking getMe probe.
  • Use NODE_OPTIONS=--dns-result-order=ipv4first to bypass IPv6 blackhole issues that trigger the 10s timeout.
  • Consider decoupling health probes from the main request flow to make them non-blocking and prevent future similar issues.
  • Optimize dashboard-v2 frontend rendering for large configuration schemas to prevent UI freezing.

Example

No code snippet is provided as the issue is more related to configuration and architecture.

Notes

The provided workarounds may not be a permanent solution and may have implications on the overall system health and monitoring. It's recommended to implement the architecture recommendations to fully resolve the issue.

Recommendation

Apply workaround: Disable the Telegram health monitor or use NODE_OPTIONS=--dns-result-order=ipv4first to mitigate the issue, as this provides a quick fix to the problem while a more permanent solution is being implemented.

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…

FAQ

Expected behavior

The dashboard menus should load asynchronously and remain responsive. A delay or timeout in a specific backend channel (e.g., Telegram API) should not block the entire gateway's event loop or freeze the user interface.

#api#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