openclaw - 💡(How to fix) Fix [Bug]: Discord Long Work Window scheduled check-ins/closeout fail after 2026.4.15 update while start message still succeeds [1 participants]

Bug type

Regression / behavior bug

Summary

After updating OpenClaw from 2026.4.2 to 2026.4.15, Discord Long Work Window runs started repeatedly failing in a specific pattern:

• the start message is delivered successfully to the Discord channel
• the actual work continues for the requested window
• but scheduled check-in and closeout messages fail to reach the Discord channel
• in multiple cases, the state file records runtime capability loss such as:
  • no message.send/message.read tool available
  • without a send/read-capable delivery path in this session

This does not look like a general Discord send failure. Direct / same-turn channel replies still work. The breakage appears to affect the cron/wake/delayed delivery path used by Long Work Window check-ins and closeouts.

Why this seems like a regression

Before the update, we had successful visible-delivery Long Work Window runs, including reply-chain check-ins and closeout. After the update to 2026.4.15, repeated failures occurred on real Discord work windows.

There is also evidence that related Discord/cron/delayed-delivery regressions have been reported by others, including:

• #62024
• #53824
• #39978
• #14753
• #58083
• #66158

Environment

• OpenClaw baseline before issue: 2026.4.2
• Updated to: 2026.4.15
• Host: macOS (native install)
• Channel: Discord guild text channels
• Long Work Window policy uses parent-session message.send + message.read visible confirmation

Affected channels / windows

1) #gun-wiki restart 30m window

• channel id: 1495634493892202657
• window id: lww-1495634493892202657-20260421T020544Z-30m
• start message id: 1495968754666836020

Observed state:

• check-in #1: attempted=false, delivered=false
• closeout: attempted=false, delivered=false
• notes: scheduled 30m check-in due, but current runtime has no message.send/message.read tool available for Discord visible delivery
• closed_reason: delivery/runtime failure; manual user follow-up required

What actually happened:

• start message was visible in Discord
• work progressed
• scheduled check-in and in-window closeout were not visibly delivered
• later manual follow-up messages appeared in channel outside the failed window

2) #azvision-dev restart 30m window

• channel id: 1489825652248150046
• window id: azvision-20260420T190303
• start message id: 1495968078180384889

Observed state:

• check-in #1: attempted=false, delivered=false
• jobs:
  • checkin: null
  • watchdog: null
  • closeout: null
• wake_fired: 0
• failure_note: check-in and closeout remained overdue without a send/read-capable delivery path in this session

What actually happened:

• start message was visible in Discord
• work progressed during the 30-minute window
• scheduled check-in failed
• closeout was only visibly delivered much later (completed_at: 2026-04-20 21:26:14 PDT), outside the original 30-minute window

Larger context

The same family of problems also appeared in longer 5-hour work windows on the same channels:

• start message visible
• work continues
• scheduled check-ins often missing
• user manual nudge sometimes causes a later reactive message
• visible delivery from the automated wake path is inconsistent or absent

This makes the issue especially concerning because internal state / work progress can continue while user-facing operational messages silently fail.

Expected behavior

For Discord Long Work Window runs:

1. start message should be delivered
2. each scheduled check-in should run through the same parent-session visible-delivery path
3. closeout should be delivered on time
4. if the wake runtime cannot access message.send / message.read, the system should fail closed before or at the first scheduled check-in, not silently continue working without visible channel delivery

Actual behavior

• start succeeds
• work continues
• scheduled check-ins / closeout fail to reach Discord
• state files show capability/path loss in the wake runtime
• later manual intervention can still produce visible messages from the main session

Strong hypothesis

The bug is likely in one or more of these areas:

1. cron/wake resumes are not always landing in the intended parent Discord session
2. the resumed runtime loses message.send / message.read capability in delayed/wake turns
3. restart/update can break cron continuity or wake registration for these windows
4. delayed delivery path can generate internal progress while skipping outbound Discord visible delivery

Why this matters

This breaks Long Work Window reliability in a dangerous way:

• work may continue
• state may change
• user-facing check-in/closeout contract is broken
• the system can appear stalled or silently fail from the user's perspective

Suggested fixes

1. Ensure cron/wake for chat-bound Long Work Windows resumes in the same parent session context with message tool capability preserved.
2. If wake runtime lacks message.send or message.read, fail closed immediately and surface a deterministic error.
3. Persist and verify actual registered cron job IDs for each scheduled slot and watchdog.
4. Add a required first scheduled check-in canary before considering any extended/long window healthy.
5. After gateway restart / update / runtime resume, require a restart canary before continuing scheduled Discord operational messages.

Current workaround

Until fixed, these workarounds reduce damage:

• treat 30-minute runs as canaries
• require start + first auto check-in + closeout visible delivery before promoting to 2h/5h runs
• after update/restart, do not trust extended windows until a canary succeeds
• if message.send/message.read capability mismatch appears once, downgrade immediately instead of letting the window continue silently

Evidence available

I can provide additional sanitized state JSON excerpts for:

• lww-1495634493892202657-20260421T020544Z-30m
• azvision-20260420T190303
• related 5-hour windows on the same channels