openclaw - 💡(How to fix) Fix Slack: native streaming gate excludes DMs even though chat.startStream accepts recipient_user_id [1 comments, 2 participants]

Summary

When channels.slack.streaming = { mode: "partial", nativeTransport: true } (default), DMs to the bot never use Slack's native streaming API (chat.startStream / chat.appendStream / chat.stopStream). They always hit the non-streaming fallback path, which posts each text-between-tools assistant block as a separate, growing Slack message.

Reproduced on 2026.4.24. The gate exists in earlier releases as well based on the surrounding code shape.

Where

dist/extensions/slack/pipeline.runtime-<hash>.js, in the streaming start branch:

const streamThreadTs = replyPlan.nextThreadTs();
plannedThreadTs = streamThreadTs;
if (!streamThreadTs) {
    logVerbose("slack-stream: no reply thread target for stream start, falling back to normal delivery");
    streamFailed = true;
    await deliverNormally({
        payload: params.payload,
        kind: params.kind
    });
    return;
}
// ...
streamSession = await startSlackStream({
    client: ctx.app.client,
    channel: message.channel,
    threadTs: streamThreadTs,
    text,
    teamId: await resolveSlackStreamRecipientTeamId({
        client: ctx.app.client,
        token: ctx.botToken,
        userId: message.user,
        fallbackTeamId: ctx.teamId
    }),
    userId: message.user
});

Why this is wrong

startSlackStream(...) already passes recipient_team_id and recipient_user_id through to client.chatStream({...}) (visible in the same bundle), and Slack's chat.startStream accepts those as the keying alternative to thread_ts for DM contexts.

The early-return on !streamThreadTs blocks every top-level DM from reaching that call, even though all required recipient context (message.user, resolved teamId) is in scope.

Reproduction

1. Configure a Slack bot with channels.slack.streaming.mode = "partial" and channels.slack.streaming.nativeTransport = true (defaults).
2. DM the bot a prompt that triggers a multi-tool agent loop (one that produces multiple text-between-tools narration blocks).
3. Observe that each narration block lands as a new Slack message instead of editing the live draft.

Suggested fix

Loosen the precondition to also let DMs through when a recipient userId is available, and let the BENIGN_SLACK_FINALIZE_ERROR_CODES recovery path catch any Slack-side rejections:

if (!streamThreadTs && !message.user) {
    // ...existing fallback...
}

Plus a small follow-up: the deliveryTracker and rememberDeliveredThreadTs calls downstream key on threadTs for dedup. For DMs that key collapses to undefined. In practice it has been fine in single-turn DMs (each turn opens a fresh stream session), but a more correct dedup key for DMs would be the returned message ts from the stream start, plumbed back through streamSession.

Severity

Medium. The fallback path is functional but its UX is bad enough that operators turn streaming off entirely. The fix is essentially a one-line gate change since the underlying transport already supports it.