Summary

When stopChannel exceeds CHANNEL_STOP_ABORT_TIMEOUT_MS (5 s), the channel runtime is left in a state where startChannelInternal silently no-ops and the health-monitor believes the restart succeeded. The channel appears running: true, connected: true in the runtime snapshot but no polling loop is active. Recovery requires a manual launchctl kickstart of the gateway.

In practice this bites Telegram polling mode after any network-stack suspend/resume event — most commonly macOS laptop sleep/wake. Polling has been dead for 6+ hours in both observed incidents while openclaw doctor reported Telegram: ok.

Reproduction

1. Run the gateway with a Telegram polling account on a MacBook.
2. Unplug the charger and close the lid (or let the machine sleep for ~30 min).
3. Wake the machine.
4. Within the next health-monitor cycle, the Telegram getUpdates long-poll socket is dead; the monitor detects stale-socket and calls stopChannel.
5. The in-flight HTTP request doesn't honor the abort within 5 s (half-closed socket after sleep). stopChannel logs channel stop exceeded 5000ms after abort; continuing shutdown and returns.
6. Telegram polling never resumes. openclaw channels status --probe shows error:channel stop timed out after 5000ms but running, connected, works.

Root cause

Two functions interact badly on the timeout path. Locations are from the bundled dist/server.impl-*.js in v2026.4.21 (npm openclaw); line numbers are from that bundle, the equivalent source paths in the repo will differ.

stopChannel (around line 2695 of the bundle): ```js if (!await waitForChannelStopGracefully(task, CHANNEL_STOP_ABORT_TIMEOUT_MS)) { log.warn?.(`[${id}] channel stop exceeded ${CHANNEL_STOP_ABORT_TIMEOUT_MS}ms after abort; continuing shutdown`); setRuntime(channelId, id, { accountId: id, running: true, // runtime still marked running restartPending: false, lastError: `channel stop timed out after ${CHANNEL_STOP_ABORT_TIMEOUT_MS}ms` }); return; // early return: store.tasks and store.aborts NOT cleared } store.aborts.delete(id); // only reached on success store.tasks.delete(id); ```

startChannelInternal (around line 2491): ```js if (store.tasks.has(id)) return; // silent no-op if a task is already registered ```

When the health-monitor runs its await stopChannel(...); await startChannel(...) sequence:

• stopChannel returns normally (doesn't throw) even on timeout.
• The zombie task reference remains in store.tasks.
• startChannelInternal sees it and returns without starting anything.
• The outer try block in the monitor completes without error, so record.lastRestartAt = now is set and a 10-minute cooldown begins.
• Every 10 min the same no-op cycle repeats; after maxRestartsPerHour (default 10) it prints "skipping" and goes silent.

Why it looks fine from the outside:

• connected is never written on the timeout path, so it stays true.
• running is explicitly set back to true.
• openclaw doctor's Telegram probe is just a getMe call on the bot token — it verifies credentials, not polling liveness.

Proposed fix

On the timeout path, release the stale task reference so the next startChannel can proceed:

```diff if (!await waitForChannelStopGracefully(task, CHANNEL_STOP_ABORT_TIMEOUT_MS)) { log.warn?.(`[${id}] channel stop exceeded ${CHANNEL_STOP_ABORT_TIMEOUT_MS}ms after abort; continuing shutdown`);

• store.aborts.delete(id);
• store.tasks.delete(id); setRuntime(channelId, id, { accountId: id,

•    running: true,

•    running: false,
     restartPending: false,
     lastError: \`channel stop timed out after \${CHANNEL_STOP_ABORT_TIMEOUT_MS}ms\`

  }); return; } ```

Safety of leaving the zombie alive: the timed-out task may still be blocked on its HTTP read. When the next polling loop calls getUpdates, Telegram returns 409 Conflict: terminated by other getUpdates request, which surfaces as an error in the zombie's poll callback and terminates it. This is the same mechanism that makes a full process restart (launchctl kickstart) work cleanly today.

Possible secondary improvement

openclaw doctor's Telegram health check currently returns OK when the bot token is valid. Consider extending it to also check that channels status --probe shows recent inbound activity (or no stop-timed-out error), so the doctor matches the liveness semantics a user expects.

Environment

• macOS 25.4.0 (Darwin), MacBook Pro M5 Max
• openclaw v2026.4.21 (npm + Homebrew cask)
• Telegram channel in polling mode

Happy to open a PR if helpful — the patch above is the entire fix as far as I can tell from the bundled output.