fix(slack): serialize follow-ups and support thread cancellation

[izadoesdev]

Slack follow-ups could run under another speaker's memory identity or remain queued after the fourth response. Process consecutive messages from each speaker together and keep draining until the thread is idle. Redis atomically checks capacity and lock ownership, and retains pending messages and deletion references long enough for the full queue to run. Coordination failures stop execution and surface a retry message.

Users can reply stop in the current conversation thread, or mention @Databuddy stop in a channel, to interrupt its response and discard earlier queued follow-ups. Cancellation preserves later requests and new clicks on older suggestion cards, works across replicas through Redis, and respects shutdown. A local active run accepts stop even if its engagement marker is missing; unrelated unengaged threads remain silent. Assistant stop dispatch does not depend on title or status API calls. Help copy documents the command.

Validation: all 95 Slack tests pass with #822 included, including sustained follow-ups, mixed speakers, expired lock owners, slow queued responses, missing engagement markers, shutdown, and failed cosmetic calls. Four combined scenarios with two native Bolt instances and an isolated, nonpersistent Redis server verify author grouping, stop cutoffs, concurrent queue capacity, replacement lock owners, duplicate deliveries, and later requests. Root lint, all 33 typecheck tasks, and all 29 pre-push test tasks pass. Independently reviewed.

Scope is Slack conversation lifecycle. No database migrations, dependencies, Slack scopes, or installation changes. Stop does not undo completed actions or cancel already submitted durable investigation jobs. Per-speaker app authorization and trusted action approvals remain separate work. AI-assisted implementation and review.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
databuddy-status	Ready	Preview	Sep 18, 2026 7:55am UTC

2 Skipped Deployments

Project	Deployment	Actions	Updated
dashboard	Skipped		Sep 18, 2026 7:55am UTC
documentation	Skipped		Sep 18, 2026 7:55am UTC

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 0e73be34-d627-46c9-8367-4e83948e57ca

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[unkey-deploy]

The latest updates on your projects. Learn more about Unkey Deploy

Name	Status	Preview	Inspect	Updated (UTC)
links (preview)	Ready	Visit Preview	Inspect	Sep 18, 2026 7:55am

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; no actionable new issue remains, and the only previous finding was fixed and manually resolved.

Summary

The PR serializes Slack follow-ups by speaker, drains thread queues until idle, and adds cross-replica thread cancellation through Redis.

• Adds atomic queue capacity, lock ownership, renewal, release, and cancellation operations.
• Allows stop to interrupt active work and discard only requests at or before the stop cutoff.
• Preserves later messages and newer interactions with older suggestion cards.
• Fails closed and provides retry guidance when coordination is unavailable.
• Adds coverage for sustained queues, multiple speakers, lock replacement, cancellation, shutdown, and duplicate delivery behavior.

Diagram

sequenceDiagram
  participant U as Slack user
  participant H as Slack handler
  participant Q as Redis thread queue
  participant A as Agent runner

  U->>H: Send message
  H->>Q: Try to acquire thread lock
  alt Lock acquired
    H->>A: Stream response
    loop Until thread is idle
      H->>Q: Renew lock and drain next speaker group
      Q-->>H: Consecutive messages from one speaker
      H->>A: Stream grouped follow-up
    end
    H->>Q: Atomically release if queue is empty
  else Lock held by another replica
    H->>Q: Atomically enqueue within capacity
  end

  U->>H: Send stop
  H->>A: Abort matching local run
  H->>Q: Record cutoff and discard earlier queued requests
  Q-->>H: Preserve requests newer than cutoff

Loading

_{Reviews (2) · Last reviewed commit: "refactor(slack): type queue results and ..."}