openclaw - 💡(How to fix) Fix Cron: false "Message failed" errors on Telegram when announce delivery uses fallback (variant of #50170) [2 comments, 3 participants]

Bug type

False error reporting (not a regression — present across multiple versions)

Summary

Cron jobs with delivery.mode: "announce" targeting Telegram (channel: telegram, to: "3521683") intermittently report status: "error" with error: "⚠️ ✉️ Message failed" despite the content being successfully delivered via fallback. The run metadata confirms fallbackUsed: true and delivered: true, yet the job status is marked as error.

This also affects cron jobs with delivery.mode: "none" — they get the same false error even though no delivery was requested.

Environment

• OpenClaw version: 2026.4.24 (cbcfdf6)
• OS: Linux 6.17.0-22-generic (x64), Ubuntu
• Channel: Telegram
• Node: v22.22.0

Affected cron jobs (different configurations, same symptom)

1. Weekly IA digest — sessionTarget: "isolated", delivery: { mode: "announce", channel: "telegram", to: "3521683" }, toolsAllow: [] (no tools restricted — agent has full access)
2. Weekly Skill Review — sessionTarget: "isolated", delivery: { mode: "none" }, toolsAllow: ["read","write","exec","memory_recall","sessions_list"]
3. Daily Critical Thinking (intermittent) — sessionTarget: "isolated", delivery: { mode: "announce", channel: "telegram", to: "3521683" }

Evidence from run metadata

Job 1 (Semanal IA) — run at 2026-04-27T08:00:00Z:

{
  "status": "error",
  "error": "⚠️ ✉️ Message failed",
  "lastDelivered": true,
  "deliveryStatus": "delivered",
  "delivery": {
    "fallbackUsed": true,
    "delivered": true
  },
  "lastDeliveryStatus": "delivered"
}

The summary field contains the actual generated content, and the cron-delivery-guard log confirms:

[2026-04-27T10:30:05+02:00] [job-id] already delivered by cron runtime — marking and exit

Job 2 (Skill Review) — run at 2026-04-27T06:55:00Z:

{
  "status": "error",
  "error": "⚠️ ✉️ Message failed",
  "delivery": {
    "mode": "none"
  },
  "deliveryStatus": "not-requested",
  "delivered": false
}

This job has delivery.mode: "none" — no delivery was ever requested, yet it gets the same "⚠️ ✉️ Message failed" error. The agent did its work correctly (saved report to disk).

Job 3 (Critical Thinking) — historical runs show same pattern:

• Most runs: status: "ok", fallbackUsed: true, delivered: true
• One run (2026-04-07): status: "error", error: "⚠️ ✉️ Message failed", delivered: false
• This shows the error is intermittent even within the same job definition

Pattern observed

The issue occurs when:

1. The isolated agent session generates a valid reply
2. The announce delivery path attempts to send via Telegram
3. Something in the primary delivery path fails (agent tries to use message tool? timing issue?)
4. The fallback delivery succeeds
5. But the job run is still marked as error because evt.error = "⚠️ ✉️ Message failed"

The error message "⚠️ ✉️ Message failed" appears to originate from the agent execution layer reporting a message tool failure, which then gets propagated as the cron job error even when fallback delivery succeeds.

Expected behavior

1. When fallbackUsed: true and delivered: true, the job should report status: "ok" — the content reached the user.
2. When delivery.mode: "none", delivery errors should never exist and should never override job execution status.

Related issues

• #50170 — Same symptom ("Message failed" despite successful Discord delivery), open with PR #50189
• #54188 — Same symptom with delivery.mode: "none", closed
• #22430 — Cron announce delivery failed - Telegram (older, possibly related)

Note on PR #50189

The PR title fix(cron): report ok status when primary delivery succeeded despite follow-up errors sounds like it should address this. If it's already merged, this issue demonstrates it's still happening on 2026.4.24. If not merged, this report provides additional Telegram-specific data to support it.

Steps to reproduce

1. Create a cron job with sessionTarget: "isolated", delivery: { mode: "announce", channel: "telegram", to: "<user-id>" }, and a prompt that makes the agent generate content and attempt delivery
2. Let it run on schedule
3. Observe the run metadata — it will eventually show status: "error" with "⚠️ ✉️ Message failed" while fallbackUsed: true and delivered: true

Intermittent — not every run triggers it, suggesting a race condition or model-dependent behavior in how the agent handles delivery.