fix(telegram): add httpTimeoutMs config for health probe timeout control (fixes #77060)#77091
fix(telegram): add httpTimeoutMs config for health probe timeout control (fixes #77060)#77091z0650115 wants to merge 4 commits into
Conversation
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. Users can now configure: channels.telegram.network.httpTimeoutMs: 5000 # 5 second timeout This prevents the gateway event loop from blocking for 10-15 seconds when the Telegram health probe encounters IPv6 blackhole issues. Fixes openclaw#77060
Fix for issue openclaw#77012 - WebChat session transcript overwritten every turn. The migration function was not idempotent - running it multiple times would regenerate IDs for entries that already had valid IDs, breaking the parent chain and causing entries to become orphaned. The root cause was that existingIds was an empty Set at the start of each migration run. When processing entries, if an entry already had an ID but that ID wasn't in existingIds (because existingIds was empty), a new ID would be generated. This would break the parentId chain since the parentId would still point to the old ID. Fix by: 1. First pass: collect all existing IDs from the file 2. Initialize existingIds with these IDs so they're preserved 3. Only assign new IDs to entries that don't have valid existing IDs This ensures that running migration multiple times produces the same result, preventing orphaned entries and broken parent chains.
Fixes issue openclaw#77054: 1. Bug 1 - read tool output not rendered: - extractToolText() 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 2. Bug 2 - exec output text clipped: - .chat-tool-card had overflow:hidden which clipped long content - Changed to overflow:auto to allow scrolling when content exceeds max-height Added tests for extractToolCards with array content blocks.
Fixes issue openclaw#77063: lossless-claw selected and enabled but not registered as context engine after plugin cache restore. Root cause: When a cached plugin registry is reused, the cached state restoration restores agent harnesses, commands, compaction providers, and memory embedding providers, but NOT registered context engines. This causes context engines registered by plugins (like lossless-claw) to be lost when the plugin loader uses cached state. Changes: - src/context-engine/registry.ts: Add RegisteredContextEngineEntry type, listRegisteredContextEngines(), and restoreRegisteredContextEngines() functions for cache snapshot/restore support - src/plugins/loader.ts: Add contextEngines field to CachedPluginState, call restoreRegisteredContextEngines() when using cached state, and save contextEngines to cache when storing registry
|
Thanks for the contribution. I reviewed the branch, and this PR is not a good landing base for OpenClaw. Close: the useful Telegram timeout-control idea is separable, but this branch is not a good landing base because it is currently conflicting and mixes a new public config surface with unrelated session transcript, WebChat tool-card, and plugin context-engine cache changes. The linked Control UI freeze path is already resolved by merged Control UI work, while the remaining Telegram timeout knob needs a focused provider PR with config-contract alignment and real probe proof. So I’m closing this PR rather than keeping an unmergeable branch open. A new narrow PR that carries only the useful part is welcome. Review detailsBest possible solution: Close this mixed branch; if maintainers still want Telegram probe timeout control, review a new Telegram-only PR that reconciles it with Do we have a high-confidence way to reproduce the issue? No high-confidence current-main reproduction remains for the linked Control UI freeze path: #77060 is closed by merged Control UI responsiveness work, and this PR provides no live Telegram probe evidence for the separate timeout knob. Is this the best way to solve the issue? No. A Telegram timeout knob may be a plausible separate provider feature, but this mixed conflicting branch is not the best solution; the maintainable path is a focused Telegram-only PR or an explicit decision to keep relying on existing bounded timeout behavior. Security review: Security review cleared: No concrete security or supply-chain regression was found; the blockers are scope, compatibility, session-state risk, conflicts, and missing real behavior proof. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 010b61746379. |
|
Overlap triage after #80657: #80657 covers the Control UI-side responsiveness path for #77060: scoped config-schema analysis before render, cached/runtime Channels status for tab entry, and stale/slow status probe protection. This PR should not be closed as a duplicate because its Telegram The current branch also bundles unrelated transcript migration, context-engine cache, and Control UI tool-card changes. Recommended split path: keep the Telegram timeout knob as a focused provider PR if still desired, and drop the unrelated changes plus the Control UI responsiveness portions already handled by #80657. |
|
This pull request has been automatically marked as stale due to inactivity. |
|
ClawSweeper applied the proposed close for this PR.
|
Fixes #77060 - Control UI menus freezing due to Telegram blocking health probe