The issue was that Discord threads always included a message_reference
(reply indicator) regardless of replyToMode setting.
The fix is Discord-specific: don't pass existingId to the reply planner
when replyToMode is 'off'. This prevents reply references in threads
while preserving the existing Slack behavior where existingId (thread_ts)
is needed to keep messages in the correct thread.
- Updated resolveDiscordReplyDeliveryPlan to check replyToMode before
setting existingId
- Updated tests to reflect new behavior
* fix(discord): gate autoThread by thread owner
* fix(discord): ack bot-owned autoThreads
* fix(discord): ack mentions in open channels
- Ack reactions in bot-owned autoThreads
- Ack reactions in open channels (no mention required)
- DRY: Pass pre-computed isAutoThreadOwnedByBot to avoid redundant checks
- Consolidate ack logic with explanatory comment
* fix: allow null values in exec.approval.request schema
The ExecApprovalRequestParamsSchema was rejecting null values for optional
fields like resolvedPath, but the calling code in bash-tools.exec.ts passes
null. This caused intermittent 'invalid exec.approval.request params'
validation errors.
Fix: Accept Type.Union([Type.String(), Type.Null()]) for all optional string
fields in the schema. Update test to reflect new behavior.
* fix: align discord ack reactions with mention gating (#1511) (thanks @pvoo)
---------
Co-authored-by: Wimmie <wimmie@tameson.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Build reply/session context once (no post-hoc ctx mutation) and type into the actual delivery target.
Thanks @davidguttman.
Co-authored-by: David Guttman <david@davidguttman.com>
