openclaw - 💡(How to fix) Fix [Bug]: Transient Telegram pairing-store read failures can trigger bogus pairing prompts [1 pull requests]

Summary

Telegram DMs can incorrectly receive an OpenClaw: access not configured pairing challenge when a transient pairing-store read fails during inbound authorization.

The observed shape is:

1. A Telegram bot has already been paired/allowed.
2. After the bot has been idle for a while, the first DM receives an access-not-configured / pairing-needed response.
3. A second DM to the same Telegram bot/chat immediately succeeds.

This is misleading because the user is not actually unpaired. A transient read failure is being interpreted like an empty pairing allowlist.

Suspected failure mode

The pairing store is a tiny JSON file, but reading it still needs a file descriptor. If the long-running gateway is under transient filesystem or descriptor pressure, fs.readFile/stat can fail even for that tiny file. Examples include EMFILE, ENFILE, EBADF, or adjacent libuv/kqueue resource failures.

Older Telegram code paths could convert a pairing-store read failure into an empty list, roughly:

readChannelAllowFromStore(...).catch(() => [])

That makes a real I/O failure look like:

paired Telegram users = []

and the bot sends a new pairing challenge instead of surfacing the transient store-read problem.

Why this matches the reported behavior

The same Telegram chat can fail once and then succeed because the account/channel identity did not change. The first message after idle is simply the first authorization path to touch the pairing store again. If that read throws once and the old handler catches it as [], Telegram sends the bogus pairing prompt. The next message can succeed once the store read succeeds.

This also fits possible gateway-level resource pressure after idle/stall:

• memory or skills watchers accumulating file descriptors,
• stale provider or Telegram sockets,
• session/transcript lock FileHandles,
• launchd soft maxfiles limits that are much lower than an interactive shell's ulimit.

The resource-pressure investigation is separate. The Telegram bug is that the transient store-read failure is presented to the user as an authorization/pairing failure.

Relevant recent context

Recent OpenClaw fixes show that FD pressure is a real class of gateway failures:

• #81802 fixed memory watcher write-polling FD pressure, including #77327 and #78224.
• #85130 fixed shared skills watcher fan-out that could hit EMFILE on multi-agent gateways, fixing #84968.

There are still related open resource-pressure issues such as #67461, #71335, #77750, #77610, #77997, and #84820.

Expected behavior

A transient pairing-store read failure should not be treated as an empty allowlist and should not create or send a new pairing challenge to an already authorized Telegram sender.

Configured allowFrom should be checked before the pairing store when it is sufficient to authorize the sender, and pairing-store reads should only happen when the effective direct-message policy requires pairing-store authorization.

Linked fix

PR #85555 changes Telegram authorization so transient pairing-store read failures no longer become bogus pairing prompts.