Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Block streaming in Slack doesn't respect replyToModeByChatType.channel = "first" [4 pull requests, 3 comments, 2 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#49341•Fetched 2026-04-08 00:56:19
View on GitHub
Comments
3
Participants
2
Timeline
12
Reactions
0
Author
mjkerrisonmjkerrison
Participants
mjkerrisonmjkerrisonRyceRyce
Timeline (top)
cross-referenced ×5commented ×3labeled ×2referenced ×2

When blockStreaming: true is enabled on the Slack channel and replyToModeByChatType.channel is set to "first", the first block of a multi-block response correctly threads under the triggering message, but subsequent blocks (e.g. text after a tool call) are posted to the main channel instead of staying in the thread, making it impossible to get both clean multi-block output AND reliable auto-threading.

Root Cause

Important: Seems to only trigger when the response pattern is text → tool → text. If the agent starts with a tool call directly (no leading text), all blocks thread correctly because no block is sent before the thread is established.

Fix Action

Fix / Workaround

Current workaround: Set requireMention: true on the Slack channel so users manually create threads before @mentioning the bot. This bypasses auto-threading entirely since all replies go to an existing thread session. Functional but adds friction — users must remember to create a thread and @mention instead of just posting in the channel.

PR fix notes

PR #49715: fix: keep slack block streaming replies in thread

Description (problem / solution / changelog)

Summary

  • Problem: with Slack blockStreaming: true and replyToModeByChatType.channel: "first", the first block replies in-thread but later blocks can fall back to the main channel.
  • Root cause: the block delivery path consumes replyPlan.nextThreadTs() once, but does not reuse the already-established usedReplyThreadTs when later block deliveries or draft-stream thread resolution run after the planner is exhausted.
  • What changed: added a small thread-resolution helper in the Slack dispatch path and reused the established thread for normal block delivery and draft-stream thread lookup once the first reply has already established the thread.
  • Why this fix: it preserves the existing precedence order (forced thread > newly planned thread > already established thread) and keeps behavior unchanged for replyToMode: "off" / "all" while fixing the first + blockStreaming regression.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • UI / DX
  • API / contracts
  • CI/CD / infra

Linked Issue/PR

  • Closes #49341

User-visible / Behavior Changes

Slack replies that use blockStreaming: true together with replyToModeByChatType.channel: "first" now keep later blocks in the same thread once the first block has established that thread.

Security Impact (required)

  • New permissions/capabilities? (Yes/No): No
  • Secrets/tokens handling changed? (Yes/No): No
  • New/changed network calls? (Yes/No): No
  • Command/tool execution surface changed? (Yes/No): No
  • Data access scope changed? (Yes/No): No

Repro + Verification

Environment

  • OS: Windows 11 (development environment)
  • Integration/channel: Slack block delivery path
  • Relevant config: blockStreaming: true, replyToModeByChatType.channel: "first"

Steps

  1. Configure Slack with block streaming enabled and channel replies in first mode.
  2. Trigger a response that emits multiple blocks.
  3. Observe thread selection across later block deliveries.

Expected

All blocks after the first reply should continue using the thread that the first reply established.

Actual

Before this change, later blocks could fall back to the main channel once replyPlan.nextThreadTs() had been consumed.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Targeted local test command:

pnpm exec vitest run extensions/slack/src/monitor/message-handler/dispatch.streaming.test.ts

Result observed locally:

  • Vitest reported 1 passed file and 7 passed tests for the targeted Slack dispatch test file.
  • In this Windows environment, the Vitest wrapper process lingered past a 10-second watchdog after printing the passing result, so the wrapper was terminated after confirming the pass output and verifying no lingering Vitest worker processes remained.

Human Verification (required)

What you personally verified:

  • The new helper preserves precedence as forced thread > planned thread > established thread.
  • The new regression tests cover both the reuse case and the precedence case.
  • git diff --check passed on the changed files.
  • oxfmt --check passed on the changed files.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

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

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this commit to restore the previous Slack block delivery thread-selection behavior.
  • Files/config to restore: extensions/slack/src/monitor/message-handler/dispatch.ts, extensions/slack/src/monitor/message-handler/dispatch.streaming.test.ts
  • Known bad symptoms reviewers should watch for: replies unexpectedly staying in a thread when an explicit forced thread or a newly planned thread should have won precedence.

Risks and Mitigations

  • Risk: later block deliveries could accidentally override an explicit thread target.
  • Mitigation: the helper keeps explicit forcedThreadTs first, planned thread second, and only falls back to the stored thread when both are absent.

Changed files

  • extensions/slack/src/monitor/message-handler/dispatch.streaming.test.ts (modified, +89/-1)
  • extensions/slack/src/monitor/message-handler/dispatch.ts (modified, +100/-13)
  • extensions/slack/src/monitor/replies.test.ts (modified, +23/-1)
  • extensions/slack/src/monitor/replies.ts (modified, +16/-4)

PR #49785: fix(slack): reuse thread ts across block deliveries in first reply mode

Description (problem / solution / changelog)

Summary

  • Fix block streaming in Slack not respecting replyToModeByChatType.channel = "first" — subsequent blocks after the first were posted to the main channel instead of staying in the thread
  • Root cause: replyPlan.nextThreadTs() returns the thread ts only once in "first" mode, so the second+ blocks got undefined and fell back to the main channel
  • Fix: fall back to usedReplyThreadTs (already tracked after first successful delivery) before consulting the reply plan, ensuring all blocks within the same agent turn stay threaded

Closes #49341

Test plan

  • Added unit tests for createSlackReplyDeliveryPlan covering all three modes (off/first/all)
  • Existing tests pass (pnpm test -- extensions/slack/src/monitor/replies.test.ts — 7/7)
  • Manual verification: configure Slack with blockStreaming: true and replyToModeByChatType.channel: "first", send a message that triggers a multi-block response (e.g. tool call + text), confirm all blocks land in the same thread

🤖 Generated with Claude Code

Changed files

  • extensions/slack/src/monitor/message-handler/dispatch.ts (modified, +16/-6)
  • extensions/slack/src/monitor/replies.test.ts (modified, +53/-1)
  • extensions/slack/src/monitor/replies.ts (modified, +1/-0)

PR #57310: fix(slack): keep block streaming replies in thread (rebased #49715)

Description (problem / solution / changelog)

Rebased and manually ported from #49715 onto current main.

Problem: With Slack blockStreaming: true and replyToModeByChatType.channel: "first", the first block replies in-thread but later blocks can fall back to the main channel.

Fix (4 commits):

  1. resolveSlackDeliveryThreadTs: reuse established thread when first-mode planning is exhausted
  2. Preserve first-mode follow-up routing with deliverNormally options
  3. Scope thread reuse to block deliveries only (via usedBlockReplyThreadTs)
  4. resolveTrackedSlackBlockReplyThreadTs: refresh cached block thread on explicit reply targets; resolveSlackDraftPreviewThreadTs: keep draft previews off-thread in replyToMode=first

Tests added for all new helpers.

Original author: @xiwuqi Closes #49341

Changed files

  • extensions/slack/src/monitor/message-handler/dispatch.streaming.test.ts (modified, +85/-0)
  • extensions/slack/src/monitor/message-handler/dispatch.ts (modified, +99/-12)
  • extensions/slack/src/monitor/replies.test.ts (modified, +23/-1)
  • extensions/slack/src/monitor/replies.ts (modified, +16/-4)

PR #1: fix(slack): fall back to usedReplyThreadTs when replyPlan exhausted

Description (problem / solution / changelog)

When blockStreaming is true and replyToMode is 'first', subsequent deliveries after the first reply get undefined thread_ts and leak into the main channel.

Fixes openclaw/openclaw#49341

Two-line fix: fall back to usedReplyThreadTs (established by first delivery) when replyPlan.nextThreadTs() returns undefined.

Changed files

  • extensions/slack/src/monitor/message-handler/dispatch.ts (modified, +2/-2)

Code Example

{
     "channels": {
       "slack": {
         "mode": "socket",
         "streaming": "off",
         "blockStreaming": true,
         "replyToModeByChatType": {
           "direct": "off",
           "channel": "first"
         }
       }
     }
   }

---

Gateway logs captured with `OPENCLAW_LOG_LEVEL=debug` on 2026-03-17.

**Broken run (text → tool → text pattern, row #6):**

The run is handled by the **channel session** (no thread suffix in key), and all deliveries go to `channel:CBF64BJM9` without `thread_ts`:


13:55:35 [agent/embedded] embedded run start: runId=f6341c05 sessionId=ec8916a6 messageChannel=slack
13:55:35 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9 prev=idle new=processing
13:55:35 [context-diag] pre-prompt: sessionKey=agent:main:slack:channel:cbf64bjm9 messages=10
13:55:42 [agent/embedded] embedded run tool start: tool=exec
13:55:42 [agent/embedded] embedded run tool end: tool=exec
13:55:43 [slack] delivered reply to channel:CBF64BJM9    ← block 1: text before tool (threaded correctly via replyToMode)
13:55:44 [slack] delivered reply to channel:CBF64BJM9    ← tool call block
13:55:44 [slack] delivered reply to channel:CBF64BJM9    ← tool result block
13:55:58 [slack] delivered reply to channel:CBF64BJM9    ← block 2: text after tool (GOES TO MAIN CHANNEL, not thread)
13:55:57 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9 prev=processing new=idle reason="run_completed"


Note: the session key is `agent:main:slack:channel:cbf64bjm9` — a bare channel session with no `:thread:<ts>` suffix. The `replyToMode: "first"` correctly threads the first block, but subsequent blocks from the same channel session do not inherit the `thread_ts` that was established by the first block's delivery.

**Working run (already in thread session):**

When the agent is already in a thread session (e.g. user replied in an existing thread), the response threads correctly:


13:51:59 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9:thread:1773745694.061389 prev=idle new=processing
13:52:05 [slack] delivered reply to channel:CBF64BJM9    ← all in thread ✅
13:52:08 [slack] delivered reply to channel:CBF64BJM9    ← all in thread ✅
13:52:13 [slack] delivered reply to channel:CBF64BJM9    ← all in thread ✅


This run was already in a thread session (note `:thread:` suffix), so all deliveries included `thread_ts`.

**Inconsistent case (text → many tools → text):**

In a longer run with multiple tool calls, the first and last text blocks went to the thread, but intermediate tool-call blocks leaked to the main channel:


21:52:44 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf917s2w prev=idle new=processing
21:52:44 [context-diag] pre-prompt: sessionKey=agent:main:slack:channel:cbf917s2w messages=0
21:52:48 [agent/embedded] embedded run tool end: tool=web_fetch
21:52:48 [slack] delivered reply to channel:CBF917S2W    ← block 1: threaded ✅
21:52:59 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
21:53:00 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
21:53:00 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
21:53:03 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
...
21:54:30 [slack] delivered reply to channel:CBF917S2W    ← final block: threaded ✅ (?)


This suggests the `thread_ts` is sometimes available for the first and last blocks but lost for intermediate ones — the behavior is inconsistent across blocks within a single run.

**`blockStreamingBreak: "message_end"` test (row #7):**


00:25:27 [reload] config change applied (dynamic reads: agents.defaults.blockStreamingBreak)
00:26:46 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9 prev=idle new=processing
00:26:50 [slack] delivered reply to channel:CBF64BJM9    ← still leaked ❌
00:26:50 [slack] delivered reply to channel:CBF64BJM9
00:27:00 [slack] delivered reply to channel:CBF64BJM9    ← still leaked ❌


`message_end` batches per assistant message, not per run. In tool-calling flows there are multiple assistant messages, so blocks still leak.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

When blockStreaming: true is enabled on the Slack channel and replyToModeByChatType.channel is set to "first", the first block of a multi-block response correctly threads under the triggering message, but subsequent blocks (e.g. text after a tool call) are posted to the main channel instead of staying in the thread, making it impossible to get both clean multi-block output AND reliable auto-threading.

Steps to reproduce

  1. Configure Slack channel with: 
    {
  "channels": {
    "slack": {
      "mode": "socket",
      "streaming": "off",
      "blockStreaming": true,
      "replyToModeByChatType": {
        "direct": "off",
        "channel": "first"
      }
    }
  }
}
  2. In a Slack channel (not DM), send a message that will cause the agent to respond with text, then a tool call, then more text (e.g. "what version of openclaw are we running and what's the latest?")
  3. Agent generates: text block → tool call → text block
  4. Observe where the two text blocks are delivered

Important: Seems to only trigger when the response pattern is text → tool → text. If the agent starts with a tool call directly (no leading text), all blocks thread correctly because no block is sent before the thread is established.

Expected behavior

We want the agent to:

  1. Auto-thread replies in channels (via replyToMode: "first") to keep the main channel clean
  2. Show tool calls as separate messages (via blockStreaming: true) so responses with tool use are readable (without block streaming, tool calls and text get concatenated into a single wall of text that's hard to parse)

Both features are documented and work individually; the bug is that they don't work together: enabling block streaming breaks auto-threading for all blocks after the first.

So, expected behaviour: All blocks of the response should be posted in the same Slack thread under the triggering message. The thread_ts from the first block's thread should be carried forward to all subsequent blocks.

Actual behavior

  • Block 1 (text before tool call): correctly posted as a threaded reply under the triggering message (✅)
  • Block 2+ (tool calls, text after tool call): posted to the originating channel as a new top-level message (❌)

The thread context (thread_ts) is lost between block deliveries.

Combinations tested (truth table)

All tested with replyToModeByChatType.channel: "first" on OpenClaw 2026.3.13.

#blockStreamingstreamingOtherAuto-threading?Readable output?Status
1falseoff—✅ Works❌ Concatenated messTested
2falsepartialnativeStreaming: true⚠️ Untested❌ Single messageNot tested
3falsepartialnativeStreaming: false⚠️ Untested❌ Single messageNot tested
4falseblock—⚠️ Untested❌ Single messageNot tested
5falseprogress—⚠️ Untested❌ Single messageNot tested
6trueoff—🐛 Broken✅ Nice blocksTested, confirmed bug
7trueoffblockStreamingBreak: "message_end"🐛 Broken✅ Nice blocksTested, still broken
8truepartial—🐛 Broken (preview skipped)✅ Nice blocksInferred (docs: preview skipped when block streaming enabled)
9trueblock—🐛 Broken (preview skipped)✅ Nice blocksInferred
10trueprogress—🐛 Broken (preview skipped)✅ Nice blocksInferred

OpenClaw version

2026.3.13 (61d171a)

Operating system

Debian 12

Install method

npm global

Model

anthropic/claude-opus-4-6

Provider / routing chain

openclaw → anthropic (direct)

Config file / key location

~/.openclaw/openclaw.json; channels.slack.blockStreaming, channels.slack.replyToModeByChatType

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Gateway logs captured with `OPENCLAW_LOG_LEVEL=debug` on 2026-03-17.

**Broken run (text → tool → text pattern, row #6):**

The run is handled by the **channel session** (no thread suffix in key), and all deliveries go to `channel:CBF64BJM9` without `thread_ts`:


13:55:35 [agent/embedded] embedded run start: runId=f6341c05 sessionId=ec8916a6 messageChannel=slack
13:55:35 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9 prev=idle new=processing
13:55:35 [context-diag] pre-prompt: sessionKey=agent:main:slack:channel:cbf64bjm9 messages=10
13:55:42 [agent/embedded] embedded run tool start: tool=exec
13:55:42 [agent/embedded] embedded run tool end: tool=exec
13:55:43 [slack] delivered reply to channel:CBF64BJM9    ← block 1: text before tool (threaded correctly via replyToMode)
13:55:44 [slack] delivered reply to channel:CBF64BJM9    ← tool call block
13:55:44 [slack] delivered reply to channel:CBF64BJM9    ← tool result block
13:55:58 [slack] delivered reply to channel:CBF64BJM9    ← block 2: text after tool (GOES TO MAIN CHANNEL, not thread)
13:55:57 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9 prev=processing new=idle reason="run_completed"


Note: the session key is `agent:main:slack:channel:cbf64bjm9` — a bare channel session with no `:thread:<ts>` suffix. The `replyToMode: "first"` correctly threads the first block, but subsequent blocks from the same channel session do not inherit the `thread_ts` that was established by the first block's delivery.

**Working run (already in thread session):**

When the agent is already in a thread session (e.g. user replied in an existing thread), the response threads correctly:


13:51:59 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9:thread:1773745694.061389 prev=idle new=processing
13:52:05 [slack] delivered reply to channel:CBF64BJM9    ← all in thread ✅
13:52:08 [slack] delivered reply to channel:CBF64BJM9    ← all in thread ✅
13:52:13 [slack] delivered reply to channel:CBF64BJM9    ← all in thread ✅


This run was already in a thread session (note `:thread:` suffix), so all deliveries included `thread_ts`.

**Inconsistent case (text → many tools → text):**

In a longer run with multiple tool calls, the first and last text blocks went to the thread, but intermediate tool-call blocks leaked to the main channel:


21:52:44 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf917s2w prev=idle new=processing
21:52:44 [context-diag] pre-prompt: sessionKey=agent:main:slack:channel:cbf917s2w messages=0
21:52:48 [agent/embedded] embedded run tool end: tool=web_fetch
21:52:48 [slack] delivered reply to channel:CBF917S2W    ← block 1: threaded ✅
21:52:59 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
21:53:00 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
21:53:00 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
21:53:03 [slack] delivered reply to channel:CBF917S2W    ← tool blocks: leaked to channel ❌
...
21:54:30 [slack] delivered reply to channel:CBF917S2W    ← final block: threaded ✅ (?)


This suggests the `thread_ts` is sometimes available for the first and last blocks but lost for intermediate ones — the behavior is inconsistent across blocks within a single run.

**`blockStreamingBreak: "message_end"` test (row #7):**


00:25:27 [reload] config change applied (dynamic reads: agents.defaults.blockStreamingBreak)
00:26:46 [diagnostic] session state: sessionKey=agent:main:slack:channel:cbf64bjm9 prev=idle new=processing
00:26:50 [slack] delivered reply to channel:CBF64BJM9    ← still leaked ❌
00:26:50 [slack] delivered reply to channel:CBF64BJM9
00:27:00 [slack] delivered reply to channel:CBF64BJM9    ← still leaked ❌


`message_end` batches per assistant message, not per run. In tool-calling flows there are multiple assistant messages, so blocks still leak.

Impact and severity

  • Affected: Any Slack channel user with blockStreaming: true + replyToMode: "first" (or replyToModeByChatType.channel: "first")
  • Severity: Medium-high (blocks the combination of two core features: auto-threading + readable multi-block output)
  • Frequency: 100% reproducible when agent response follows the text → tool → text pattern. Does NOT seem to occur when agent starts with a tool call directly.
  • Consequence: Thread conversations become fragmented; users see partial responses in threads and orphaned continuations in the channel. Users must choose between readable output (block streaming) or reliable threading (no block streaming).

Additional information

Root cause hypothesis: When blockStreaming sends the first text block, replyToMode: "first" creates a Slack thread and posts the block there. However, the thread_ts returned from that first post is not fed back into the delivery context for subsequent blocks in the same run. The channel session's deliveryContext remains { "channel": "slack", "to": "channel:<id>" } without threadTs, so blocks 2+ go to the main channel.

Related issues:

  • #10837 (deliveryContext missing thread_ts) — same underlying pattern, fixed for non-blockStreaming path
  • #20337 / #20377 (streaming + thread delivery failures) — fixed for native streaming path
  • Both fixes appear to not cover the blockStreaming delivery path

Current workaround: Set requireMention: true on the Slack channel so users manually create threads before @mentioning the bot. This bypasses auto-threading entirely since all replies go to an existing thread session. Functional but adds friction — users must remember to create a thread and @mention instead of just posting in the channel.

extent analysis

Fix Plan

To fix the issue, we need to modify the delivery context to include the thread_ts for subsequent blocks when blockStreaming is enabled. Here are the steps:

  • Modify the deliveryContext to store the thread_ts from the first block's response.
  • Update the blockStreaming delivery path to include the thread_ts in the delivery context for subsequent blocks.
  • Ensure that the thread_ts is properly propagated to the deliveryContext for each block in the response.

Example code changes:

// Store thread_ts in deliveryContext
const deliveryContext = {
  channel: 'slack',
  to: 'channel:<id>',
  threadTs: null, // Add threadTs property
};

// Update blockStreaming delivery path
if (blockStreaming) {
  const firstBlockResponse = await sendFirstBlock();
  deliveryContext.threadTs = firstBlockResponse.thread_ts;
  // Subsequent blocks will use the stored thread_ts
  for (const block of subsequentBlocks) {
    await sendBlock(block, deliveryContext);
  }
}

// Send block function
async function sendBlock(block, deliveryContext) {
  const options = {
    channel: deliveryContext.channel,
    text: block.text,
    thread_ts: deliveryContext.threadTs, // Include thread_ts in options
  };
  await slackClient.postMessage(options);
}

Verification

To verify that the fix worked, test the following scenarios:

  • Send a message that triggers a response with multiple blocks (text → tool → text).
  • Verify that all blocks are posted in the same Slack thread under the triggering message.
  • Test with different response patterns (e.g., tool → text → tool) to ensure that the fix works consistently.

Extra Tips

  • Ensure that the thread_ts is properly handled for each block in the response to avoid losing the thread context.
  • Consider adding logging or debugging statements to verify that the thread_ts is being stored and propagated correctly.
  • Review related issues (#10837, #20337, #20377) to ensure that the fix does not introduce any regressions.

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

We want the agent to:

  1. Auto-thread replies in channels (via replyToMode: "first") to keep the main channel clean
  2. Show tool calls as separate messages (via blockStreaming: true) so responses with tool use are readable (without block streaming, tool calls and text get concatenated into a single wall of text that's hard to parse)

Both features are documented and work individually; the bug is that they don't work together: enabling block streaming breaks auto-threading for all blocks after the first.

So, expected behaviour: All blocks of the response should be posted in the same Slack thread under the triggering message. The thread_ts from the first block's thread should be carried forward to all subsequent blocks.

#api#ssr#installation#tensor shape#autograd error#LLM response#prompt template#agent execution#callback error#memory management

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]: Block streaming in Slack doesn't respect replyToModeByChatType.channel = "first" [4 pull requests, 3 comments, 2 participants]