Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Telegram channel starts but never finishes initialization or receives inbound updates [2 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#61570•Fetched 2026-04-08 02:57:12
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
thebaronofsdthebaronofsd
Participants
neeravmakwananeeravmakwanathebaronofsdthebaronofsd
Timeline (top)
cross-referenced ×2closed ×1commented ×1

Error Message

  • no visible error is logged
  • no Telegram error log

Fix Action

Fixed

PR fix notes

PR #61596: fix(telegram): bound startup request timeouts

Description (problem / solution / changelog)

Summary

  • Problem: Telegram could report healthy/running while provider startup was still hung before inbound polling or webhook setup actually finished.
  • Why it matters: inbound Telegram updates could silently never start even though health checks still passed.
  • What changed: centralized Telegram Bot API request timeout resolution and added bounded startup/control-plane timeouts for getMe, setWebhook, and deleteWebhook while keeping the longer getUpdates timeout.
  • What did NOT change (scope boundary): no routing/session behavior changes, no config changes, and no changes to Telegram retry policy beyond letting existing retry handling recover from startup stalls.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #61570
  • Related #61570
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: only getUpdates had a hard request timeout; Telegram startup/control-plane calls could block indefinitely before polling or webhook setup completed.
  • Missing detection / guardrail: there was no startup-path timeout guard for deleteWebhook, getMe, or setWebhook, even though gateway runtime state is set to running before the provider fully hands off to a healthy steady state.
  • Contributing context (if known): health probing uses getMe separately from the runtime startup path, so health could still look OK while startup was stuck on a different Bot API request.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: extensions/telegram/src/request-timeouts.test.ts
  • Scenario the test should lock in: startup/control-plane Telegram methods (deleteWebhook, getMe, setWebhook) stay bounded while getUpdates keeps the longer polling timeout.
  • Why this is the smallest reliable guardrail: the wrapper already had timeout behavior coverage for getUpdates; this adds direct coverage for the newly bounded startup methods without expanding the Telegram runtime surface.
  • Existing test that already covers this (if any): extensions/telegram/src/monitor.test.ts already covers retry/restart behavior once startup cleanup errors are surfaced.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

Telegram startup now fails/retries instead of hanging indefinitely when Telegram Bot API startup calls stall before inbound polling or webhook setup becomes active.

Diagram (if applicable)

Before:
[gateway starts Telegram] -> [startup control-plane call hangs] -> [channel looks healthy/running] -> [no inbound updates]

After:
[gateway starts Telegram] -> [startup control-plane call hits timeout] -> [existing retry/error path runs] -> [startup recovers or surfaces failure]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS (darwin 25.3.0)
  • Runtime/container: local repo workspace
  • Model/provider: N/A
  • Integration/channel (if any): Telegram
  • Relevant config (redacted): Telegram bot token configured; startup in polling or webhook mode

Steps

  1. Start Telegram with valid bot credentials.
  2. Let a startup-path Bot API call (deleteWebhook, getMe, or setWebhook) stall.
  3. Observe that inbound startup never reaches a healthy steady state even though health probing can still succeed independently.

Expected

  • Telegram startup should not hang indefinitely on startup-path Bot API calls.
  • A stalled startup call should time out and fall into the existing retry/error path.

Actual

  • Startup-path Bot API calls could previously hang forever, leaving Telegram apparently healthy/running while inbound startup never completed.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: pnpm build; pnpm check; OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test extensions/telegram/src/request-timeouts.test.ts extensions/telegram/src/monitor.test.ts
  • Edge cases checked: startup-only timeout coverage for deleteWebhook, getMe, setWebhook; preserved longer getUpdates timeout; unrelated Telegram methods remain unbounded by this helper.
  • What you did not verify: live Telegram bot startup against a real account.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: startup timeouts could be too aggressive on unusually slow Telegram control-plane requests.
    • Mitigation: only startup/control-plane methods are bounded to 15s, getUpdates keeps its longer polling timeout, and existing recoverable retry handling remains in place.

AI Assistance

  • AI-assisted
  • Testing level: pnpm build, pnpm check, and targeted Telegram regression tests above.
  • I reviewed the change end-to-end and understand the code paths touched.

Made with Cursor

Changed files

  • extensions/telegram/src/bot.ts (modified, +2/-4)
  • extensions/telegram/src/request-timeouts.test.ts (added, +19/-0)
  • extensions/telegram/src/request-timeouts.ts (added, +15/-0)

PR #61601: fix(telegram): bound startup request timeouts

Description (problem / solution / changelog)

Summary

  • Problem: Telegram could report healthy/running while provider startup was still hung before inbound polling or webhook setup actually finished.
  • Why it matters: inbound Telegram updates could silently never start even though health checks still passed.
  • What changed: centralized Telegram Bot API request timeout resolution and added bounded startup/control-plane timeouts for getMe, setWebhook, and deleteWebhook while keeping the longer getUpdates timeout.
  • What did NOT change (scope boundary): no routing/session behavior changes, no config changes, and no changes to Telegram retry policy beyond letting existing retry handling recover from startup stalls.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #61570
  • Related #61570
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: only getUpdates had a hard request timeout; Telegram startup/control-plane calls could block indefinitely before polling or webhook setup completed.
  • Missing detection / guardrail: there was no startup-path timeout guard for deleteWebhook, getMe, or setWebhook, even though gateway runtime state is set to running before the provider fully hands off to a healthy steady state.
  • Contributing context (if known): health probing uses getMe separately from the runtime startup path, so health could still look OK while startup was stuck on a different Bot API request.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: extensions/telegram/src/request-timeouts.test.ts
  • Scenario the test should lock in: startup/control-plane Telegram methods (deleteWebhook, getMe, setWebhook) stay bounded while getUpdates keeps the longer polling timeout.
  • Why this is the smallest reliable guardrail: the wrapper already had timeout behavior coverage for getUpdates; this adds direct coverage for the newly bounded startup methods without expanding the Telegram runtime surface.
  • Existing test that already covers this (if any): extensions/telegram/src/monitor.test.ts already covers retry/restart behavior once startup cleanup errors are surfaced.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

Telegram startup now fails/retries instead of hanging indefinitely when Telegram Bot API startup calls stall before inbound polling or webhook setup becomes active.

Diagram (if applicable)

Before:
[gateway starts Telegram] -> [startup control-plane call hangs] -> [channel looks healthy/running] -> [no inbound updates]

After:
[gateway starts Telegram] -> [startup control-plane call hits timeout] -> [existing retry/error path runs] -> [startup recovers or surfaces failure]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS (darwin 25.3.0)
  • Runtime/container: local repo workspace
  • Model/provider: N/A
  • Integration/channel (if any): Telegram
  • Relevant config (redacted): Telegram bot token configured; startup in polling or webhook mode

Steps

  1. Start Telegram with valid bot credentials.
  2. Let a startup-path Bot API call (deleteWebhook, getMe, or setWebhook) stall.
  3. Observe that inbound startup never reaches a healthy steady state even though health probing can still succeed independently.

Expected

  • Telegram startup should not hang indefinitely on startup-path Bot API calls.
  • A stalled startup call should time out and fall into the existing retry/error path.

Actual

  • Startup-path Bot API calls could previously hang forever, leaving Telegram apparently healthy/running while inbound startup never completed.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: pnpm build; pnpm check; OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test extensions/telegram/src/request-timeouts.test.ts extensions/telegram/src/monitor.test.ts
  • Edge cases checked: startup-only timeout coverage for deleteWebhook, getMe, setWebhook; preserved longer getUpdates timeout; unrelated Telegram methods remain unbounded by this helper.
  • What you did not verify: live Telegram bot startup against a real account.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: startup timeouts could be too aggressive on unusually slow Telegram control-plane requests.
    • Mitigation: only startup/control-plane methods are bounded to 15s, getUpdates keeps its longer polling timeout, and existing recoverable retry handling remains in place.

AI Assistance

  • AI-assisted
  • Testing level: pnpm build, pnpm check, and targeted Telegram regression tests above.
  • I reviewed the change end-to-end and understand the code paths touched.

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/telegram/src/bot.ts (modified, +2/-4)
  • extensions/telegram/src/request-timeouts.test.ts (added, +19/-0)
  • extensions/telegram/src/request-timeouts.ts (added, +15/-0)

Code Example

2026-04-05T23:48:07.245Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider

---

2026-04-05T23:58:55.983Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider
RAW_BUFFERClick to expand / collapse

I’m seeing what looks like a Telegram provider/runtime issue in OpenClaw.

Environment

  • OpenClaw version: 2026.4.2
  • OS: Linux 6.6.87.2-microsoft-standard-WSL2
  • Gateway: local
  • Telegram bot reported by health check: @watsonbettle_bot

Symptoms

Telegram used to work, but after troubleshooting/restarts it no longer receives inbound messages.

Current behavior:

  • Telegram channel shows as enabled
  • openclaw status --deep reports Telegram OK
  • health check identifies the expected bot account
  • sending a DM to the bot does not create a session
  • no inbound Telegram update/message logs appear
  • no visible error is logged

Status / health output

Deep status shows Telegram healthy:

  • Channel: Telegram ON / OK
  • Health: ok (@watsonbettle_bot:default:357ms)

Relevant logs

After restart, Telegram only logs:

2026-04-05T23:48:07.245Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider

After another restart:

2026-04-05T23:58:55.983Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider

What never appears:

  • no Telegram: ok
  • no inbound update log
  • no inbound message log
  • no session creation
  • no Telegram error log

Repro steps

  1. Restart gateway
  2. Confirm openclaw status --deep shows Telegram OK
  3. Send DM (ping) to the Telegram bot
  4. Check logs

Expected behavior

Inbound Telegram message is logged and a Telegram session is created or reused.

Actual behavior

Provider logs starting provider only, then appears to hang silently. No inbound updates are consumed.

What I already ruled out

  • sessions.json issue
  • deleted session archive issue
  • Telegram allowlist issue
  • pairing issue
  • stale Telegram runtime/cache files on disk (none found besides credentials)
  • wrong bot account (health check reports expected bot)

Additional notes

This looks like the Telegram provider is able to pass health/auth checks but is not completing startup or consuming updates.

extent analysis

TL;DR

The Telegram provider in OpenClaw may not be fully initializing, causing it to miss inbound messages, and checking the provider's startup process and configuration is necessary.

Guidance

  • Verify the Telegram provider's configuration and credentials to ensure they are correct and properly set up.
  • Check for any updates or changes to the Telegram API that may be affecting the provider's ability to consume updates.
  • Investigate the provider's startup process to see if there are any issues or errors that are not being logged.
  • Consider enabling more verbose logging for the Telegram provider to gain more insight into its startup and operation.

Example

No specific code snippet is available without more information about the OpenClaw and Telegram provider implementation.

Notes

The issue may be related to a specific version of OpenClaw or the Telegram provider, and checking the version history and release notes may provide more information.

Recommendation

Apply workaround: Investigate and debug the Telegram provider's startup process and configuration to identify and fix the issue, as the problem seems to be related to the provider not fully initializing.

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

Inbound Telegram message is logged and a Telegram session is created or reused.

#agent execution#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING