Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: slack responses delivered to wrong thread or outside of thread [2 pull requests, 3 comments, 4 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75969•Fetched 2026-05-03 04:43:43
View on GitHub
Comments
3
Participants
4
Timeline
10
Reactions
2
Author
dchekmarevdchekmarev
Participants
clawsweeper[bot]clawsweeper[bot]dchekmarevdchekmarevGodsBoyGodsBoymartingarramonmartingarramon
Timeline (top)
commented ×3cross-referenced ×2labeled ×2mentioned ×1

2026.04.26, 2026.04.27, 2026.04.29 To be honest I'm not long with openclaw, so haven't seen unaffected version.

2 issues:

  1. sometimes message into channel root gets linked to one of earlier threads.
  2. sometimes message into thread gets unlinked and arrives into channel root.

This leads to wrong decisions, agent assumes I answer "yes" to something it posted earlier or injects wrong context into thread.

For me looks sort of critical.

Root Cause

2026.04.26, 2026.04.27, 2026.04.29 To be honest I'm not long with openclaw, so haven't seen unaffected version.

2 issues:

  1. sometimes message into channel root gets linked to one of earlier threads.
  2. sometimes message into thread gets unlinked and arrives into channel root.

This leads to wrong decisions, agent assumes I answer "yes" to something it posted earlier or injects wrong context into thread.

For me looks sort of critical.

Fix Action

Fixed

PR fix notes

PR #75995: [WIP] test: add session linkage verification for Slack roomish channels with replyToMode=all

Description (problem / solution / changelog)

Summary

  • Problem: Slack roomish channels ignore replyToMode="all", causing top-level messages to share a single session.
  • Why it matters: This leads to race conditions where responses to different messages in the same channel are routed to the same session, causing incorrect thread routing.
  • What changed: Added a comprehensive test matrix to prove the bug and verify existing behavior for other modes.
  • What did NOT change: No production code changes yet (TDD approach).

Change Type

  • Bug fix (tests only)

Scope

  • Integrations (Slack)

Root Cause

  • Root cause: resolveSlackRoutingContext has a guard isRoomish ? roomThreadId : ... that blocks autoThreadId for roomish channels, even when replyToMode="all" is set.
  • Missing detection: No tests were covering the interaction between isRoomish and replyToMode="all".

Regression Test Plan

  • Coverage level: Unit test
  • Target test: extensions/slack/src/monitor/message-handler/prepare-routing.race-condition.test.ts
  • Scenario: Verify that replyToMode="all" produces distinct session keys for roomish channels, while other modes (off, first) maintain shared sessions.

Routing State Matrix (TDD)

Channel TypereplyToModeExpected SessionActual BehaviorStatus
RoomallDistinct (:thread:<ts>)Shared (Channel)❌ Fail
Roomoff / first / batchedShared (Channel)Shared (Channel)✅ Pass
Group DMAnyShared (Channel)Shared (Channel)✅ Pass
Direct MessageAnyShared (User)Shared (User)✅ Pass
FallbackallDistinct (:thread:<ts>)Shared (Channel)❌ Fail
Fallbackoff / first / batchedShared (Channel)Shared (Channel)✅ Pass

Evidence

The tests in prepare-routing.race-condition.test.ts currently fail for the all mode in roomish channels, confirming the bug.

Human Verification

  • Verified that replyToMode="off" and "first" still result in shared sessions (no regression).
  • Verified that Group DMs and DMs behave as expected.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Changed files

  • extensions/slack/src/monitor/message-handler/prepare-routing.race-condition.test.ts (added, +138/-0)
  • extensions/slack/src/monitor/message-handler/prepare.thread-session-key.test.ts (modified, +10/-3)

PR #75630: fix(slack): harden thread continuation gating

Description (problem / solution / changelog)

This is a follow-up to #58731 after the SDK-backed Slack thread participation persistence landed on main. I rebased onto the current state-store path, dropped the competing JSON participation store from this branch, and removed the unrelated Dockerfile assertion from the original branch.

Changes:

  • use the existing SDK-backed thread participation lookup for mention gating
  • remove the unreliable child-ts conversations.replies fallback path
  • preserve cached unresolved replies as _ambiguousThreadReply
  • drop ambiguous thread replies before they can be treated as root channel messages
  • wire threadContinuation through the legacy mention-gating helpers
  • add focused regression coverage for the review feedback

Validation:

  • pnpm test extensions/slack/src/sent-thread-cache.test.ts extensions/slack/src/monitor/message-handler/prepare.test.ts extensions/slack/src/monitor/monitor.thread-resolution.test.ts extensions/slack/src/monitor.threading.missing-thread-ts.test.ts src/channels/mention-gating.test.ts

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/slack/src/monitor.threading.missing-thread-ts.test.ts (modified, +2/-0)
  • extensions/slack/src/monitor/message-handler/dispatch.preview-fallback.test.ts (modified, +2/-0)
  • extensions/slack/src/monitor/message-handler/dispatch.ts (modified, +8/-0)
  • extensions/slack/src/monitor/message-handler/prepare.test.ts (modified, +26/-0)
  • extensions/slack/src/monitor/message-handler/prepare.ts (modified, +62/-13)
  • extensions/slack/src/monitor/message-handler/types.ts (modified, +2/-0)
  • extensions/slack/src/monitor/monitor.thread-resolution.test.ts (modified, +26/-0)
  • extensions/slack/src/monitor/thread-resolution.ts (modified, +19/-17)
  • extensions/slack/src/types.ts (modified, +6/-0)
  • src/channels/mention-gating.test.ts (modified, +30/-0)
  • src/channels/mention-gating.ts (modified, +17/-2)

Code Example

"channels": {
    "slack": {
      "enabled": true,
      "botToken": "removed",
      "appToken": "removed",
      "groupPolicy": "open",
      "capabilities": {
        "interactiveReplies": true
      },
      "dmPolicy": "pairing",
      "allowFrom": [
        "*"
      ],
      "dm": {
        "enabled": true
      },
      "channels": {
        "C0AR2L9F7SP": {
          "requireMention": false
        }
      },
      "replyToMode": "all",
      "streaming": {
        "mode": "partial",
        "nativeTransport": true,
        "preview": {
          "toolProgress": false
        }
      }
    }
  },

---
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

2026.04.26, 2026.04.27, 2026.04.29 To be honest I'm not long with openclaw, so haven't seen unaffected version.

2 issues:

  1. sometimes message into channel root gets linked to one of earlier threads.
  2. sometimes message into thread gets unlinked and arrives into channel root.

This leads to wrong decisions, agent assumes I answer "yes" to something it posted earlier or injects wrong context into thread.

For me looks sort of critical.

Steps to reproduce

don't have exact steps to reproduce, feels spurious, but since 2026.04.29 happens more frequently vs 2026.04.26.

Expected behavior

Messages in web ui (sessions) MUST appear as responses to corresponding threads in slack.

Actual behavior

Sometimes messages from slack appear in sessions which have no linkage to threads where messages actually posted.

OpenClaw version

2026.04.29

Operating system

Ubuntu 24.04

Install method

docker

Model

qwen 3.6 30B A3B

Provider / routing chain

slack -> openclaw

Additional provider/model setup details

slack config:

 "channels": {
    "slack": {
      "enabled": true,
      "botToken": "removed",
      "appToken": "removed",
      "groupPolicy": "open",
      "capabilities": {
        "interactiveReplies": true
      },
      "dmPolicy": "pairing",
      "allowFrom": [
        "*"
      ],
      "dm": {
        "enabled": true
      },
      "channels": {
        "C0AR2L9F7SP": {
          "requireMention": false
        }
      },
      "replyToMode": "all",
      "streaming": {
        "mode": "partial",
        "nativeTransport": true,
        "preview": {
          "toolProgress": false
        }
      }
    }
  },

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Review and adjust the Slack configuration, particularly the replyToMode and groupPolicy settings, to ensure correct message threading in OpenClaw.

Guidance

  • Verify the replyToMode setting is correctly configured to handle replies and threads in the Slack channel.
  • Check the groupPolicy setting to ensure it aligns with the expected behavior for message threading.
  • Investigate the streaming configuration, specifically the mode and nativeTransport settings, to see if they impact message handling.
  • Test the configuration with a simplified setup to isolate the issue and identify potential conflicts.

Example

No code snippet is provided as the issue is related to configuration settings.

Notes

The issue seems to be related to the interaction between OpenClaw and Slack, and adjusting the configuration settings may resolve the problem. However, without more information on the expected behavior and the specific use case, it's difficult to provide a more detailed solution.

Recommendation

Apply workaround: Adjust the Slack configuration settings to ensure correct message threading, as the issue seems to be related to the configuration rather than a version-specific bug.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Messages in web ui (sessions) MUST appear as responses to corresponding threads in slack.

#cache error#pipeline error#runtime error#dependency conflict#environment setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: slack responses delivered to wrong thread or outside of thread [2 pull requests, 3 comments, 4 participants]