Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Restart sentinel notification lost: sentinel consumed before Telegram channel is ready [1 comments, 2 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#52220•Fetched 2026-04-08 01:14:05
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
0
Author
yyxiaohuiyyxiaohui
Participants
Hollychou924Hollychou924yyxiaohuiyyxiaohui
Timeline (top)
commented ×1

After a config.patch restart, the restart sentinel notification is silently lost because the sentinel is consumed ~750ms after startup, but the Telegram bot provider doesn't start until ~3s after startup.

Root Cause

In server-startup.ts, the sentinel wake is scheduled with a 750ms setTimeout:

if (shouldWakeFromRestartSentinel()) setTimeout(() => {
    scheduleRestartSentinelWake({ deps: params.deps });
}, 750);

But in the gateway log, the Telegram provider doesn't start until ~3s after startup:

18:28:03.161 [gateway] listening on ws://127.0.0.1:18789 (PID 9344)
18:28:05.101 [telegram] [default] starting provider (@bot)

The sentinel file is consumed (deleted) at ~750ms, but deliverOutboundPayloads fails silently because the Telegram channel isn't connected yet.

Fix Action

Workaround

Using a launchd WatchPaths watcher on the sentinel file that waits 15s then sends via Telegram Bot API directly.

Code Example

if (shouldWakeFromRestartSentinel()) setTimeout(() => {
    scheduleRestartSentinelWake({ deps: params.deps });
}, 750);

---

18:28:03.161 [gateway] listening on ws://127.0.0.1:18789 (PID 9344)
18:28:05.101 [telegram] [default] starting provider (@bot)
RAW_BUFFERClick to expand / collapse

Summary

After a config.patch restart, the restart sentinel notification is silently lost because the sentinel is consumed ~750ms after startup, but the Telegram bot provider doesn't start until ~3s after startup.

Steps to Reproduce

  1. Run config.patch with a note parameter
  2. Gateway restarts via SIGUSR1
  3. Expected: User receives the note as a Telegram message
  4. Actual: No notification received

Root Cause

In server-startup.ts, the sentinel wake is scheduled with a 750ms setTimeout:

if (shouldWakeFromRestartSentinel()) setTimeout(() => {
    scheduleRestartSentinelWake({ deps: params.deps });
}, 750);

But in the gateway log, the Telegram provider doesn't start until ~3s after startup:

18:28:03.161 [gateway] listening on ws://127.0.0.1:18789 (PID 9344)
18:28:05.101 [telegram] [default] starting provider (@bot)

The sentinel file is consumed (deleted) at ~750ms, but deliverOutboundPayloads fails silently because the Telegram channel isn't connected yet.

Suggested Fix

scheduleRestartSentinelWake should wait for at least one channel to be connected/ready before attempting delivery, or use a longer initial delay (e.g., 5-10s), or retry delivery if the first attempt fails.

Workaround

Using a launchd WatchPaths watcher on the sentinel file that waits 15s then sends via Telegram Bot API directly.

Environment

  • OpenClaw 2026.3.13
  • macOS (Darwin arm64)
  • Channel: Telegram (polling mode)

extent analysis

Fix Plan

To fix the issue, we need to modify the scheduleRestartSentinelWake function to wait for the Telegram channel to be connected before attempting delivery. Here are the steps:

  • Modify server-startup.ts to wait for the Telegram channel to be connected:
if (shouldWakeFromRestartSentinel()) {
  // Wait for Telegram channel to be connected
  const telegramChannelReady = new Promise((resolve) => {
    const intervalId = setInterval(() => {
      if (isTelegramChannelConnected()) {
        clearInterval(intervalId);
        resolve();
      }
    }, 100);
  });

  telegramChannelReady.then(() => {
    scheduleRestartSentinelWake({ deps: params.deps });
  });
}
  • Alternatively, you can use a longer initial delay (e.g., 5-10s) to ensure the Telegram channel is connected:
if (shouldWakeFromRestartSentinel()) setTimeout(() => {
  scheduleRestartSentinelWake({ deps: params.deps });
}, 5000); // 5s delay
  • Another option is to retry delivery if the first attempt fails:
if (shouldWakeFromRestartSentinel()) {
  scheduleRestartSentinelWake({ deps: params.deps });
  // Retry delivery if it fails
  setTimeout(() => {
    if (!wasDeliverySuccessful()) {
      scheduleRestartSentinelWake({ deps: params.deps });
    }
  }, 1000); // 1s retry delay
}

Verification

To verify the fix, restart the gateway and check if the notification is received via Telegram. You can also add logging to verify that the scheduleRestartSentinelWake function is called after the Telegram channel is connected.

Extra Tips

  • Make sure to implement a timeout for the telegramChannelReady promise to prevent it from waiting indefinitely.
  • Consider adding a retry mechanism with exponential backoff to handle cases where the Telegram channel is not connected after a certain amount of time.

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…
#api#prompt template#agent execution#callback error#memory management

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 Restart sentinel notification lost: sentinel consumed before Telegram channel is ready [1 comments, 2 participants]