Summary

On OpenClaw 2026.4.9 (0512059) on Linux, a Telegram direct lane repeatedly throws:

TypeError: Cannot read properties of undefined (reading 'length')

The lane is not fully dead, because some sendMessage calls still succeed between failures, but the same Telegram direct session keeps re-entering the crash path.

This looks like either:

• malformed content/history block handling in a Telegram lane, or
• a regression adjacent to the existing reading 'length' compaction/shape-validation issues

Environment

• OpenClaw: 2026.4.9 (0512059)
• Host: Linux 6.8.0-107-generic x64
• Node: v25.8.1
• Channel: Telegram

Important exclusions

These log warnings were present on the same host but are known unrelated noise and should not be conflated with this issue:

• memory-lancedb-pro invalid config: embedding: must have required property 'embedding'
• plugin disabled (disabled in config) but config is present
• Discord health monitor intentionally disabled as workaround for a separate issue family

Evidence

Representative lines from journalctl for the same Telegram direct lane:

2026-04-09T19:33:23.194-07:00 [diagnostic] lane task error: lane=session:agent:<redacted>:telegram:direct:<redacted> durationMs=10124 error="TypeError: Cannot read properties of undefined (reading 'length')"
2026-04-09T19:34:58.821-07:00 [diagnostic] lane task error: lane=session:agent:<redacted>:telegram:direct:<redacted> durationMs=51260 error="TypeError: Cannot read properties of undefined (reading 'length')"
2026-04-09T19:39:38.400-07:00 [diagnostic] lane task error: lane=session:agent:<redacted>:telegram:direct:<redacted> durationMs=6345 error="TypeError: Cannot read properties of undefined (reading 'length')"
2026-04-09T19:39:38.799-07:00 [telegram] sendMessage ok chat=<redacted> message=<redacted>
2026-04-09T19:39:59.634-07:00 [telegram] sendMessage ok chat=<redacted> message=<redacted>

This same pattern persisted for a much wider window on the host, with repeated failures over time rather than one isolated exception.

Expected behavior

A malformed or partial content block should be ignored, normalized, or treated as zero-length. It should not repeatedly crash the Telegram lane task.

Actual behavior

The Telegram direct lane repeatedly throws Cannot read properties of undefined (reading 'length'), then partially recovers enough to send some messages, then throws again.

Why this seems related upstream

This may be related to existing malformed-block / compaction-estimation bug families, but this host presents it specifically through a Telegram direct lane:

• [Bug]: Malformed tool result content block crashes context truncation in a session-permanent loop #34979 malformed tool result content block crashes context truncation when block.text is missing
• Main session prompt crash: Cannot read properties of undefined (reading 'length') in compaction token estimation #63612 compaction token estimation crash on Cannot read properties of undefined (reading 'length')
• [Bug]: 2026.4.9 multi-channel degradation on Linux: Discord direct-session overflow + slash lag + Telegram 'reading length' lane crashes #64034 combined field report from the same host where this Telegram failure appeared alongside Discord direct-session overflow/compaction instability

Impact

• Telegram reliability is degraded
• lane failures recur instead of self-healing cleanly
• user-visible behavior is intermittent and confusing because some sends still succeed between crashes

Request

Please advise whether this should be folded into one of the existing malformed-history / compaction-estimation issues, or tracked as a Telegram-specific manifestation of the same underlying bug family.

If needed, I can add a larger sanitized log slice showing the longer repeated-error window.