openclaw - 💡(How to fix) Fix Mattermost thread reply path is not debuggable: thread-session targeting is blocked and parent relay can fail as NO_REPLY

Summary

While validating Mattermost threaded reply delivery for OpenClaw, I hit a hard debugging boundary in the send/orchestration path:

1. direct thread-session targeting is rejected by orchestration
2. the fallback parent-channel relay path accepts the send
3. the live send can still end in NO_REPLY instead of a visible threaded reply
4. the send surface does not expose the actual payload fields needed to debug root/thread routing

This leaves threaded reply failures effectively opaque from the current surface.

Reproduction

Confirmed on 2026-05-21 against OpenClaw 2026.5.18 (50a2481).

1. Use sessions_send against a Mattermost thread session

2. Observe the explicit orchestration error:

   sessions_send cannot target a thread session for inter-agent coordination. Use the parent channel session key instead.

3. Retry through the parent channel session to force a visible reply into the active Mattermost thread

4. Observe that the send is accepted/pending, but the live test can still terminate as NO_REPLY rather than producing the threaded visible reply

5. Attempt to inspect the delivery details and observe that the current surface does not expose:

   • replyToMode
   • threadRootId
   • outgoing rootId
   • accountId
   • final Mattermost POST body

Expected Behavior

One of these should be true:

• OpenClaw should support a first-class threaded visible reply path from the relevant session surface, or
• if parent-channel relay is the intended design, it should either deliver reliably or return a concrete delivery failure with the actual root/thread payload details

At minimum, when a threaded send fails, the runtime should surface enough structured payload data to debug the issue without instrumenting the Mattermost delivery layer separately.

Actual Behavior

• Direct thread-session targeting is blocked before delivery
• Parent-channel relay is accepted but can still fail to produce the visible threaded reply
• The terminal observable result can be NO_REPLY
• No root/thread payload details are surfaced, so it is impossible to confirm whether the failure is:
  • missing/wrong rootId
  • wrong reply mode selection
  • wrong account/channel binding
  • bad final POST shape
  • or a higher-level relay/session decision

Why This Matters

This blocks debugging for exactly the class of failures we most need to diagnose: thread-reply discipline in Mattermost. It also creates a false-confidence shape where the relay is "accepted" but not actually proven delivered.

For agent operations, this makes it hard to distinguish:

• agent silence
• orchestration refusal
• reply-routing failure
• Mattermost delivery failure

Those are different failure classes, but the current surface compresses them into too little evidence.

Suggested Fix

Any of the following would materially improve this:

1. Add first-class support for sending a visible Mattermost threaded reply from the correct session surface
2. Treat parent-session NO_REPLY on an intended visible delivery as a failed send, not a soft/silent outcome
3. Expose structured debug fields for the actual delivery attempt:
   • replyToMode
   • threadRootId
   • outgoing rootId
   • channelId
   • accountId
   • final POST target/body shape (redacted as needed)
4. Return an explicit delivery result object for Mattermost sends instead of collapsing into accepted/pending followed by NO_REPLY

Additional Notes

• This is adjacent to earlier Mattermost/OpenClaw thread-routing anomalies where the visible behavior looked like agent non-responsiveness, but the actual problem was delivery/routing shape
• From this surface, payload-level debugging cannot progress further without instrumentation on the actual Mattermost delivery layer