Bug: notify() drops messages when runtime sender is missing or throws instead of falling back

[fujiwaranosai850]

Problem

notify() in lib/dispatch/notify.ts is runtime-first, but if runtime exists and the channel sender is missing or throws, the notification is dropped instead of falling back to openclaw message send.

This leads to user-visible notification loss for failures like:

Cannot read properties of undefined (reading 'sendMessageTelegram')

Current behavior

The current logic is effectively:

if (runtime) {
  await runtime.channel.telegram.sendMessageTelegram(...)
  return true
}

await runCommand(["openclaw", "message", "send", ...])

wrapped in an outer try/catch.

That means:

• CLI/OpenClaw fallback is only used when runtime is absent
• if runtime is present but runtime.channel.telegram is undefined, or the runtime sender throws, the outer catch logs notify_error and returns false
• the message is never handed off to OpenClaw's normal outbound delivery path

Why this is a bug

Runtime-first is reasonable for performance and for avoiding CLI/WebSocket timeout issues.

But once runtime send fails, notification delivery should still fall back to the standard OpenClaw send path. Right now the failure mode is effectively silent best-effort message loss.

For worker lifecycle notifications, if the user never sees the message, the message was effectively not sent.

Expected behavior

If runtime sender lookup fails, or runtime send throws, notify() should:

1. log the runtime failure
2. fall back to openclaw message send
3. only return false if both runtime send and fallback fail

Suggested fix

Refactor sendMessage() so it:

• safely resolves the runtime sender for the selected channel
• uses runtime send only if that sender exists
• on runtime error, tries CLI/OpenClaw fallback
• logs delivery path used, for example:
  • runtime
  • cli-fallback
  • failed

Notes

This is distinct from earlier related issues:

• Fix dispatch timeout causing missed Telegram notifications #153, which explains the move to runtime-first delivery
• Bug: Heartbeat notifications fail with 'runCommand is required when runtime is not available' #453, which covered heartbeat notification failure when runtime / runCommand context was missing

Those explain why runtime-first exists, but they do not address the missing fallback when runtime send itself fails.

[fujiwaranosai850]

Local execution tracking for reproduction and fix work is in yaqub0r/devclaw#7: yaqub0r#7

[fujiwaranosai850]

Update from local execution: local issue #7 had to be reopened after live production validation still showed notify_error with Cannot read properties of undefined (reading 'sendMessageTelegram') after PR #9 merged. The local workflow close was premature; investigation is continuing on the real production execution path. Local tracking: yaqub0r#7