Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Telegram polling creates new HTTPS connection every ~10 seconds instead of reusing keepalive connections [2 comments, 3 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#75114•Fetched 2026-05-01 05:38:02
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
2
Author
hpinho77hpinho77
Participants
clawsweeper[bot]clawsweeper[bot]hpinho77hpinho77steipetesteipete
Timeline (top)
commented ×2closed ×1labeled ×1referenced ×1

Code Example

Gateway PID: 21935
Telegram ESTABLISHED (lsof): 9
TIME_WAIT total: 54,668
Telegram TIME_WAIT: 29,755
PCB count: 55,615
MSL: 1000ms
TCP states:
  TIME_WAIT: 54,668
  SYN_SENT: 938
  FIN_WAIT_1: 46
  ESTABLISHED: 23
  LISTEN: 21
  FIN_WAIT_2: 9

Active connections from gateway (lsof -p 21935):
  9 × 149.154.166.110:443 (Telegram)
  2 × [fe80:19::4a6:bf5b:524d:861e]:1025
  2 × 20.90.66.7:443
  2 × 100.109.127.127:62078
  2 × 100.109.127.127:58178
  2 × 100.109.127.127:49347
  1 × 4.207.247.137:443
  1 × 34.36.133.15:443
  1 × 17.188.178.124:5223

---

15:02:55: ESTABLISHED=9 TIME_WAIT=29639
15:03:00: ESTABLISHED=9 TIME_WAIT=29639
15:03:05: ESTABLISHED=9 TIME_WAIT=29639
15:03:11: ESTABLISHED=9 TIME_WAIT=29639
15:03:16: ESTABLISHED=6 TIME_WAIT=29643  ← connection recycled
15:03:21: ESTABLISHED=6 TIME_WAIT=29644

---

2026-04-30T14:37:02.498+01:00 [gateway] http server listening (4 plugins: memory-core, memory-wiki, openclaw-web-search, telegram; 7.1s)
2026-04-30T14:37:33.024+01:00 [telegram] [job-searcher] starting provider (@Skorpy_ClawJobsBot)
2026-04-30T14:37:33.314+01:00 [telegram] [default] starting provider (@Skorpy_ClawBot)
2026-04-30T14:37:33.543+01:00 [telegram] [rnd-council] starting provider (@skorpy_claw_rndbot)

---
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Environment

  • OpenClaw version: 2026.4.27
  • macOS: 26.3.1 (Darwin 25.3.0 arm64)
  • Gateway PID: 21935
  • Node: v25.8.1
  • Date: 2026-04-30

Steps to Reproduce

  1. Run openclaw gateway start
  2. Monitor connections: while true; do echo "$(date): $(netstat -an | grep '149.154.166.110.443' | grep TIME_WAIT | wc -l)"; sleep 10; done
  3. Observe: TIME_WAIT count increases by ~6 every 10 seconds

Expected Behavior

  • Long polling should use 1-3 persistent HTTPS connections per Telegram bot account
  • Connections should be reused via HTTP keepalive
  • No new connections should be created during normal polling
  • TIME_WAIT count should remain stable (only old connections decay, no new ones added)

Actual Behavior

  • Gateway creates ~6 new connections to api.telegram.org every 10 seconds
  • Old connections go to TIME_WAIT (1 second MSL = ~1 second decay per connection)
  • Net effect: TIME_WAIT grows by ~5-6 per 10-second cycle
  • After 1 hour: ~18,000+ new TIME_WAIT connections created
  • Gateway currently shows 9 ESTABLISHED connections to Telegram (should be 1-3)

Diagnostic Data

Gateway PID: 21935
Telegram ESTABLISHED (lsof): 9
TIME_WAIT total: 54,668
Telegram TIME_WAIT: 29,755
PCB count: 55,615
MSL: 1000ms
TCP states:
  TIME_WAIT: 54,668
  SYN_SENT: 938
  FIN_WAIT_1: 46
  ESTABLISHED: 23
  LISTEN: 21
  FIN_WAIT_2: 9

Active connections from gateway (lsof -p 21935):
  9 × 149.154.166.110:443 (Telegram)
  2 × [fe80:19::4a6:bf5b:524d:861e]:1025
  2 × 20.90.66.7:443
  2 × 100.109.127.127:62078
  2 × 100.109.127.127:58178
  2 × 100.109.127.127:49347
  1 × 4.207.247.137:443
  1 × 34.36.133.15:443
  1 × 17.188.178.124:5223

Connection Growth Pattern (monitored)

15:02:55: ESTABLISHED=9 TIME_WAIT=29639
15:03:00: ESTABLISHED=9 TIME_WAIT=29639
15:03:05: ESTABLISHED=9 TIME_WAIT=29639
15:03:11: ESTABLISHED=9 TIME_WAIT=29639
15:03:16: ESTABLISHED=6 TIME_WAIT=29643  ← connection recycled
15:03:21: ESTABLISHED=6 TIME_WAIT=29644

Pattern: ~6 new connections created per 10 seconds, ~6 go to TIME_WAIT

Impact

  • PCB count increasing (55k+ and growing)
  • Port resource exhaustion risk over time
  • CPU overhead from repeated TCP handshakes
  • Stale TIME_WAIT sockets accumulating

Additional Context

  • This occurs even with the active-memory plugin disabled
  • Occurs with all 3 Telegram bots (default, job-searcher, rnd-council)
  • Gateway restart does not help — leak resumes immediately after restart
  • Connection count jumped from 6 to 9 after gateway restart, suggesting multiple polling loops

Gateway Log (recent)

2026-04-30T14:37:02.498+01:00 [gateway] http server listening (4 plugins: memory-core, memory-wiki, openclaw-web-search, telegram; 7.1s)
2026-04-30T14:37:33.024+01:00 [telegram] [job-searcher] starting provider (@Skorpy_ClawJobsBot)
2026-04-30T14:37:33.314+01:00 [telegram] [default] starting provider (@Skorpy_ClawBot)
2026-04-30T14:37:33.543+01:00 [telegram] [rnd-council] starting provider (@skorpy_claw_rndbot)

Steps to reproduce

  1. Run openclaw gateway start
  2. Monitor connections: while true; do echo "$(date): $(netstat -an | grep '149.154.166.110.443' | grep TIME_WAIT | wc -l)"; sleep 10; done
  3. Observe: TIME_WAIT count increases by ~6 every 10 seconds

Expected behavior

  • Long polling should use 1-3 persistent HTTPS connections per Telegram bot account
  • Connections should be reused via HTTP keepalive
  • No new connections should be created during normal polling
  • TIME_WAIT count should remain stable (only old connections decay, no new ones added)

Actual behavior

  • Gateway creates ~6 new connections to api.telegram.org every 10 seconds
  • Old connections go to TIME_WAIT (1 second MSL = ~1 second decay per connection)
  • Net effect: TIME_WAIT grows by ~5-6 per 10-second cycle
  • After 1 hour: ~18,000+ new TIME_WAIT connections created
  • Gateway currently shows 9 ESTABLISHED connections to Telegram (should be 1-3)

OpenClaw version

2026.4.27

Operating system

macOS: 26.3.1 (Darwin 25.3.0 arm64)

Install method

No response

Model

minimax-m2.7:cloud

Provider / routing chain

openclaw → ollama → minimax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue can be mitigated by adjusting the HTTP keepalive settings to properly reuse existing connections, potentially through configuration changes in the OpenClaw gateway or the Telegram plugin.

Guidance

  1. Review HTTP Keepalive Configuration: Check the OpenClaw gateway and Telegram plugin configurations for any settings related to HTTP keepalive. Ensure that keepalive is enabled and the timeout is set appropriately to allow for connection reuse.
  2. Adjust Connection Pooling: If the Telegram plugin or OpenClaw gateway uses connection pooling, review the pool size and settings. Increasing the pool size or adjusting the idle connection timeout might help in reusing existing connections instead of creating new ones.
  3. Monitor and Adjust MSL: Although the MSL (Maximum Segment Lifetime) is set to 1000ms, monitor its impact on the connection growth pattern. Adjusting this value might influence how quickly connections move to the TIME_WAIT state and are eventually closed.
  4. Inspect Plugin Interactions: Given that the issue occurs with all three Telegram bots and the connection count increases after a gateway restart, inspect how the plugins interact with the gateway and each other. There might be a logic or configuration issue causing unnecessary connections to be established.

Example

No specific code example can be provided without knowing the exact configuration or codebase of the OpenClaw gateway and its plugins. However, a general approach to enabling HTTP keepalive in a Node.js environment (given Node version v25.8.1 is used) might involve setting the keepAlive and keepAliveTimeout options when creating an HTTPS agent.

Notes

The provided information suggests a potential issue with how connections are managed between the OpenClaw gateway and the Telegram API. However, without direct access to the code or more detailed configuration settings, the suggestions are based on general principles of connection management and keepalive mechanisms.

Recommendation

Apply a workaround by adjusting the HTTP keepalive settings and monitoring the connection growth pattern

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

  • Long polling should use 1-3 persistent HTTPS connections per Telegram bot account
  • Connections should be reused via HTTP keepalive
  • No new connections should be created during normal polling
  • TIME_WAIT count should remain stable (only old connections decay, no new ones added)
#api#autograd error#model save/load#optimization#mixed precision

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 - 💡(How to fix) Fix [Bug]: Telegram polling creates new HTTPS connection every ~10 seconds instead of reusing keepalive connections [2 comments, 3 participants]