openclaw - 💡(How to fix) Fix Telegram isolated polling spool can be blocked by stale .processing claim after PID reuse

Summary

In OpenClaw 2026.5.22, a Telegram isolated polling account can stop responding when an old *.json.processing claim remains in /home/node/.openclaw/telegram/ingress-spool-<account>/ and a later gateway process reuses the same numeric PID recorded in that claim.

The affected Telegram accounts had valid bot configuration and updates were present in the per-account spool, but the queued updates did not drain until the stale .processing files were manually requeued.

Environment

• OpenClaw: 2026.5.22
• Deployment: Docker image-based deployment
• Host: Windows 11 + WSL2 + Docker
• Channel: Telegram isolated polling ingress

Observed behavior

• Some Telegram accounts continued working normally.
• Two Telegram accounts stopped producing replies.
• Their spool directories contained an old *.json.processing file plus newer .json updates behind it.
• After stopping the gateway, backing up /home/node/.openclaw/telegram, and renaming only the stale *.json.processing files back to .json, the queued updates drained and replies resumed.

Suspected cause

The stale processing claim appears to be considered live because the current gateway process reused the same PID stored in the old claim. In container restarts, numeric PIDs can repeat, so PID alone is not a reliable owner identity.

Expected behavior

Stale spool claims should be recoverable even if a later process has the same numeric PID. Claim recovery should compare a unique process/session identity, gateway start time, or claim age relative to the current gateway process.

Workaround used

1. Stop gateway.
2. Back up /home/node/.openclaw/telegram.
3. Rename only stale affected *.json.processing files back to .json.
4. Restart gateway.

No update files were deleted.

Request

Please review the Telegram isolated polling spool claim recovery logic so stale claims cannot block an account indefinitely after PID reuse.