openclaw - 💡(How to fix) Fix Slack message sends can return ambiguous middlewareError, causing duplicate retries

Summary

Slack message(action="send") can return an ambiguous tool result such as:

{
  "details": {"status": "error", "middlewareError": true},
  "isError": false
}

When this happens, the agent receives no Slack messageId / receipt and cannot tell whether the message was actually delivered. In a live Slack channel this led to visible duplicate assistant replies because the agent treated the tool result as a failed send and retried.

Environment

• OpenClaw package: openclaw 2026.5.12
• Runtime: macOS Darwin 25.5.0 arm64
• Node: v24.15.0
• Provider/channel: Slack channel
• Agent: main

Observed behavior

During a Slack channel conversation, several message tool calls returned middleware errors without receipts, while the Slack channel showed repeated/near-duplicate visible assistant messages.

Redacted local session evidence:

line 637  timestamp 1779123359744  toolName=message  isError=false  details={"status":"error","middlewareError":true}
line 640  timestamp 1779123389573  toolName=message  isError=false  details={"status":"error","middlewareError":true}
line 643  timestamp 1779123436670  toolName=message  isError=false  details={"status":"error","middlewareError":true}
line 646  timestamp 1779123464239  toolName=message  isError=false  details={"status":"error","middlewareError":true}
line 652  timestamp 1779123649748  toolName=message  isError=false  details={"status":"error","middlewareError":true}
line 655  timestamp 1779123711654  toolName=message  isError=false  details={"status":"error","middlewareError":true}
line 658  timestamp 1779123782120  toolName=message  isError=false  details={"status":"error","middlewareError":true}

For comparison, normal successful Slack sends in the same session return a receipt like:

{
  "result": {
    "receipt": {
      "primaryPlatformMessageId": "1779124612.540739",
      "platformMessageIds": ["1779124612.540739"],
      "parts": [{"platformMessageId": "1779124612.540739", "kind": "text"}]
    },
    "messageId": "1779124612.540739",
    "channel": "slack"
  }
}

There was also an earlier related Slack durable-send style error in the same session logs:

details={"status":"error","tool":"message","error":"Required durable message send is unsupported for slack: missing reconcileUnknownSend"}

Expected behavior

For Slack sends, the tool result should make retry safety explicit:

1. If the message was delivered, return a receipt / platform message id.
2. If delivery definitely failed before Slack accepted the request, return a clear failed status and isError: true.
3. If delivery is unknown, return a distinct unknown_send_state (or similar) plus enough reconciliation data for the agent/runtime to check Slack before retrying.
4. Ideally, provide an idempotency/reconciliation key so repeated agent attempts do not create duplicate visible messages.

Actual behavior

message(action="send") returned status:error + middlewareError:true while isError:false, with no platform receipt. This created an ambiguous state. The agent retried and duplicate messages became visible in Slack.

Impact

• User-facing duplicate replies in Slack.
• Agent cannot know whether to retry safely.
• Long-running task status updates become unreliable; users may see repeated explanations or believe the assistant is stuck.

Suggested fix

• Treat Slack middleware send failures as one of: delivered, definitely_failed, or unknown.
• For unknown, expose an explicit retry-safety flag such as retrySafe: false / sendState: "unknown".
• Implement or expose Slack reconcileUnknownSend support for durable sends.
• Consider idempotency keys for message(action="send") so retry attempts can be de-duplicated by the runtime/plugin.

I am filing this with private channel content redacted; I can provide more local session metadata if useful.