Skip to content

feat(slack): handle inbound reaction_added events - #44508

Closed
harrisonmedmedmetrics wants to merge 1 commit into
NousResearch:mainfrom
harrisonmedmedmetrics:feat/slack-reaction-added-handler
Closed

feat(slack): handle inbound reaction_added events#44508
harrisonmedmedmetrics wants to merge 1 commit into
NousResearch:mainfrom
harrisonmedmedmetrics:feat/slack-reaction-added-handler

Conversation

@harrisonmedmedmetrics

@harrisonmedmedmetrics harrisonmedmedmetrics commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Problem

The Slack adapter (gateway/platforms/slack.py) registers @self._app.event(...) handlers for message, app_mention, and the file lifecycle events — but none for reaction_added. In Socket Mode, Slack delivers the reaction_added event over the websocket, but with no handler bound, Bolt silently drops it (at most an "unhandled request" log).

The practical effect: reaction-driven workflows never fire. A common pattern — react ✅ on a bot-posted card to approve/trigger an action — does nothing, and there's no clear signal why. Users typically chase this on the Slack side (re-adding the reactions:read scope, re-subscribing the event, reinstalling the app) when in fact the scope/subscription are correct and the gap is purely that Hermes never listens for the event.

Fix

Add a reaction_added handler that routes approval emojis through the existing _handle_slack_message pipeline by synthesizing a mention-shaped event. Reusing that pipeline means the reaction path inherits, for free:

  • allowed-channel gating (_slack_allowed_channels())
  • channel_prompt injection and channel skills
  • session keying / thread context
  • the 👀/✅/❌ processing reaction lifecycle

Design details:

  • Approval set: white_check_mark, heavy_check_mark, ballot_box_with_check. Other reactions are ignored.
  • Loop-safe: ignores the bot's own reactions (the processing lifecycle adds ✅/❌ itself).
  • Only message items: file/other reaction targets are skipped.
  • Synthetic event embeds the real bot mention token (<@bot_uid>) so the existing require_mention gate passes naturally — no special-casing inside _handle_slack_message.
  • Dedup-safe ts: the synthetic event's ts is the reaction's event_ts, not the reacted message's ts (the MessageDeduplicator keys on ts and would otherwise drop it as a duplicate of the already-seen card). thread_ts is set to the reacted message ts so the reply threads under the card.
  • Also acks reaction_removed so Bolt stops logging unhandled-request warnings for it.

Tests

New TestReactionAdded class in tests/gateway/test_slack.py:

  • approval reaction dispatches a correctly-shaped synthetic message (channel, thread_ts, unique ts, embedded mention, reacted-text context)
  • non-approval emoji → no dispatch
  • bot's own reaction → no dispatch
  • non-message item (e.g. file) → no dispatch
  • reaction in a non-allowed channel → no dispatch
  • survives _fetch_thread_parent_text raising (still dispatches)

Full Slack suite green locally: 200 passed (194 existing + 6 new). py_compile clean.

Notes

  • Net +208 / -0 across two files; no existing behavior changed (purely additive event handlers + the new method).
  • The approval-emoji set is currently a module constant; happy to make it config-driven (e.g. slack.approval_reactions) if preferred.

@harrisonmedmedmetrics
feat(slack): handle inbound reaction_added events
ab0ee87 
The Slack adapter registered handlers for message, app_mention, and file
events but had no handler for reaction_added. Slack delivers the event over
Socket Mode, but with no @app.event("reaction_added") binding Bolt silently
drops it — so reaction-driven workflows (e.g. react ✅ on a
card to approve it) never fire no matter how the app is reinstalled.

Add a reaction_added handler that routes approval emojis through the normal
_handle_slack_message pipeline as a synthetic mention, inheriting
allowed-channel gating, channel_prompt injection, session keying, and the
reaction lifecycle. Also ack reaction_removed to silence unhandled-request
logging. Includes unit tests covering dispatch on approval emoji and
non-dispatch for non-approval / bot's own / non-message-item / non-allowed
channel, plus survival of thread-text fetch failure.
@alt-glitch alt-glitch added type/feature New feature or request comp/gateway Gateway runner, session dispatch, delivery platform/slack Slack app adapter P3 Low — cosmetic, nice to have labels Jun 11, 2026
teknium1
teknium1 reviewed Jul 14, 2026
View reviewed changes

@teknium1 teknium1 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for identifying the reaction-event gap. Current main still registers reaction_added but no-ops it at plugins/platforms/slack/adapter.py:1121-1127, so the feature request remains live.

Problems

  • The PR targets gateway/platforms/slack.py, but Slack was migrated to plugins/platforms/slack/adapter.py by 560010547. This needs a port rather than a direct cherry-pick.
  • gateway/platforms/slack.py:2215 hard-codes the synthetic event as channel_type="channel". Current routing only infers D-prefixed channels as DMs when that field is absent (plugins/platforms/slack/adapter.py:2759-2763) and emits source type from that result (:3163-3176), so a DM reaction would be classified as a group interaction.
  • The current no-op handlers were deliberately added in 82d570165 for acknowledgement only. The agent-triggering approval contract needs maintainer confirmation during salvage.

Suggested changes

  • Port the implementation and tests to the bundled Slack plugin path.
  • Preserve/derive conversation type and add DM/MPIM source and session-scope coverage.

Automated hermes-sweeper review.

Comment thread gateway/platforms/slack.py
"text": instruction,
"user": reactor,
"channel": channel_id,
"channel_type": "channel",

@teknium1 teknium1 Jul 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This misclassifies reactions in DMs: current Slack code only infers im for D-prefixed channels when channel_type is absent, then uses the result for source/session routing. Omit this field when unavailable or derive the actual conversation type, and add DM/MPIM coverage.

@teknium1 teknium1 added sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:risk-security-boundary Sweeper risk: may affect sandboxing, auth, credentials, or sensitive data sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 14, 2026
teknium1 pushed a commit that referenced this pull request Jul 23, 2026
@bpross @teknium1
fix(slack): forward reaction_added events to the message pipeline
48390c5 
Slack reaction_added events were explicitly acked and dropped, so a user
reacting to a bot message (👍 to approve, ✅ to acknowledge) produced
nothing. Forward them through the normal message pipeline as synthesized
MessageEvents whose text is the reaction emoji (translated to unicode
for common names), keeping the downstream auth gate, thread-context
fetch, dedup, and skill routing unchanged.

- Self-reactions and non-message items are dropped; reactions on
  messages not sent by this bot are dropped (Feishu-adapter parity).
- The reacted-to message's thread parent becomes the synthesized
  thread_ts so the reaction lands in the same session as a reply would.
- Manifest gains reactions:read scope + reaction_added bot event.

Salvaged from PR #29916 by @bpross.
Related: #33111, #44508, #45265 (same cluster).
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1 @johnkattenhorn
@Kev-fs @harrisonmedmedmetrics
feat(slack): opt-in reaction triggers, removed events, hooks, channel…
9db9c72 
… handoff

Build the full reaction pipeline on top of the #29916 base:

- Opt-in gate: slack.reaction_triggers (default OFF — reaction events
  stay acked-and-dropped so busy channels don't wake the agent on every
  emoji). 'true' routes reactions on the bot's OWN messages; an explicit
  emoji-name list routes those emojis from any message (handoff flows).
- reaction_removed events now route too, distinguished by the
  cross-platform text convention reaction:added:<emoji> /
  reaction:removed:<emoji> (matches the Feishu and Photon adapters, so
  agents and skills see one shape everywhere).
- Authorization: the reactor becomes the synthesized message's user, so
  the early _is_user_authorized gate and allowed_channels whitelist
  apply exactly as for typed messages. _hermes_force_process only skips
  the mention requirement (a reaction on the bot's own message is
  definitionally addressed to the bot), mirroring Feishu/Photon.
- Gateway hooks (#33111 by @johnkattenhorn): every human reaction on a
  message item fires reaction:added / reaction:removed through the new
  BasePlatformAdapter.set_reaction_handler → GatewayRunner
  ._handle_reaction_event → HookRegistry.emit, independent of the
  routing opt-in. Documented in hooks.md.
- Channel handoff (#45265 by @Kev-fs): slack.reaction_trigger_target
  routes the reaction turn to a configured channel (top-level via
  _hermes_no_thread_response + reply-anchor suppression in
  gateway/platforms/base.py) or C123:<ts> thread.
- Manifest: reaction_removed event subscription added alongside
  reaction_added/reactions:read.
- Docs: slack.md Reaction Triggers section; hooks.md event table rows.

Also credits #44508 by @harrisonmedmedmetrics (inbound reaction_added
handling — same plumbing class, superseded by this consolidated shape).

Co-authored-by: johnkattenhorn <john.kattenhorn.personal@gmail.com>
Co-authored-by: Kev-fs <kevin@fleetsmarts.net>
Co-authored-by: harrisonmedmedmetrics <harrison@medmetricsrx.com>
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1
chore(release): map C17 reaction-cluster contributor emails
1b6fe7c 
- john.kattenhorn.personal@gmail.com -> johnkattenhorn (#33111)
- harrison@medmetricsrx.com -> harrisonmedmedmetrics (#44508)
- kevin@fleetsmarts.net -> Kev-fs (#45265)
@teknium1 teknium1 mentioned this pull request Jul 23, 2026
Merged
teknium1 pushed a commit that referenced this pull request Jul 23, 2026
@bpross @teknium1
fix(slack): forward reaction_added events to the message pipeline
80d404d 
Slack reaction_added events were explicitly acked and dropped, so a user
reacting to a bot message (👍 to approve, ✅ to acknowledge) produced
nothing. Forward them through the normal message pipeline as synthesized
MessageEvents whose text is the reaction emoji (translated to unicode
for common names), keeping the downstream auth gate, thread-context
fetch, dedup, and skill routing unchanged.

- Self-reactions and non-message items are dropped; reactions on
  messages not sent by this bot are dropped (Feishu-adapter parity).
- The reacted-to message's thread parent becomes the synthesized
  thread_ts so the reaction lands in the same session as a reply would.
- Manifest gains reactions:read scope + reaction_added bot event.

Salvaged from PR #29916 by @bpross.
Related: #33111, #44508, #45265 (same cluster).
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1 @johnkattenhorn
@Kev-fs @harrisonmedmedmetrics
feat(slack): opt-in reaction triggers, removed events, hooks, channel…
f10bbb2 
… handoff

Build the full reaction pipeline on top of the #29916 base:

- Opt-in gate: slack.reaction_triggers (default OFF — reaction events
  stay acked-and-dropped so busy channels don't wake the agent on every
  emoji). 'true' routes reactions on the bot's OWN messages; an explicit
  emoji-name list routes those emojis from any message (handoff flows).
- reaction_removed events now route too, distinguished by the
  cross-platform text convention reaction:added:<emoji> /
  reaction:removed:<emoji> (matches the Feishu and Photon adapters, so
  agents and skills see one shape everywhere).
- Authorization: the reactor becomes the synthesized message's user, so
  the early _is_user_authorized gate and allowed_channels whitelist
  apply exactly as for typed messages. _hermes_force_process only skips
  the mention requirement (a reaction on the bot's own message is
  definitionally addressed to the bot), mirroring Feishu/Photon.
- Gateway hooks (#33111 by @johnkattenhorn): every human reaction on a
  message item fires reaction:added / reaction:removed through the new
  BasePlatformAdapter.set_reaction_handler → GatewayRunner
  ._handle_reaction_event → HookRegistry.emit, independent of the
  routing opt-in. Documented in hooks.md.
- Channel handoff (#45265 by @Kev-fs): slack.reaction_trigger_target
  routes the reaction turn to a configured channel (top-level via
  _hermes_no_thread_response + reply-anchor suppression in
  gateway/platforms/base.py) or C123:<ts> thread.
- Manifest: reaction_removed event subscription added alongside
  reaction_added/reactions:read.
- Docs: slack.md Reaction Triggers section; hooks.md event table rows.

Also credits #44508 by @harrisonmedmedmetrics (inbound reaction_added
handling — same plumbing class, superseded by this consolidated shape).

Co-authored-by: johnkattenhorn <john.kattenhorn.personal@gmail.com>
Co-authored-by: Kev-fs <kevin@fleetsmarts.net>
Co-authored-by: harrisonmedmedmetrics <harrison@medmetricsrx.com>
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1
chore(release): map C17 reaction-cluster contributor emails
7cfb922 
- john.kattenhorn.personal@gmail.com -> johnkattenhorn (#33111)
- harrison@medmetricsrx.com -> harrisonmedmedmetrics (#44508)
- kevin@fleetsmarts.net -> Kev-fs (#45265)
teknium1 pushed a commit that referenced this pull request Jul 23, 2026
@bpross @teknium1
fix(slack): forward reaction_added events to the message pipeline
c82d257 
Slack reaction_added events were explicitly acked and dropped, so a user
reacting to a bot message (👍 to approve, ✅ to acknowledge) produced
nothing. Forward them through the normal message pipeline as synthesized
MessageEvents whose text is the reaction emoji (translated to unicode
for common names), keeping the downstream auth gate, thread-context
fetch, dedup, and skill routing unchanged.

- Self-reactions and non-message items are dropped; reactions on
  messages not sent by this bot are dropped (Feishu-adapter parity).
- The reacted-to message's thread parent becomes the synthesized
  thread_ts so the reaction lands in the same session as a reply would.
- Manifest gains reactions:read scope + reaction_added bot event.

Salvaged from PR #29916 by @bpross.
Related: #33111, #44508, #45265 (same cluster).
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1 @johnkattenhorn
@Kev-fs @harrisonmedmedmetrics
feat(slack): opt-in reaction triggers, removed events, hooks, channel…
2b35fbb 
… handoff

Build the full reaction pipeline on top of the #29916 base:

- Opt-in gate: slack.reaction_triggers (default OFF — reaction events
  stay acked-and-dropped so busy channels don't wake the agent on every
  emoji). 'true' routes reactions on the bot's OWN messages; an explicit
  emoji-name list routes those emojis from any message (handoff flows).
- reaction_removed events now route too, distinguished by the
  cross-platform text convention reaction:added:<emoji> /
  reaction:removed:<emoji> (matches the Feishu and Photon adapters, so
  agents and skills see one shape everywhere).
- Authorization: the reactor becomes the synthesized message's user, so
  the early _is_user_authorized gate and allowed_channels whitelist
  apply exactly as for typed messages. _hermes_force_process only skips
  the mention requirement (a reaction on the bot's own message is
  definitionally addressed to the bot), mirroring Feishu/Photon.
- Gateway hooks (#33111 by @johnkattenhorn): every human reaction on a
  message item fires reaction:added / reaction:removed through the new
  BasePlatformAdapter.set_reaction_handler → GatewayRunner
  ._handle_reaction_event → HookRegistry.emit, independent of the
  routing opt-in. Documented in hooks.md.
- Channel handoff (#45265 by @Kev-fs): slack.reaction_trigger_target
  routes the reaction turn to a configured channel (top-level via
  _hermes_no_thread_response + reply-anchor suppression in
  gateway/platforms/base.py) or C123:<ts> thread.
- Manifest: reaction_removed event subscription added alongside
  reaction_added/reactions:read.
- Docs: slack.md Reaction Triggers section; hooks.md event table rows.

Also credits #44508 by @harrisonmedmedmetrics (inbound reaction_added
handling — same plumbing class, superseded by this consolidated shape).

Co-authored-by: johnkattenhorn <john.kattenhorn.personal@gmail.com>
Co-authored-by: Kev-fs <kevin@fleetsmarts.net>
Co-authored-by: harrisonmedmedmetrics <harrison@medmetricsrx.com>
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1
chore(release): map C17 reaction-cluster contributor emails
9d44757 
- john.kattenhorn.personal@gmail.com -> johnkattenhorn (#33111)
- harrison@medmetricsrx.com -> harrisonmedmedmetrics (#44508)
- kevin@fleetsmarts.net -> Kev-fs (#45265)
teknium1 pushed a commit that referenced this pull request Jul 23, 2026
@bpross @teknium1
fix(slack): forward reaction_added events to the message pipeline
9c9b057 
Slack reaction_added events were explicitly acked and dropped, so a user
reacting to a bot message (👍 to approve, ✅ to acknowledge) produced
nothing. Forward them through the normal message pipeline as synthesized
MessageEvents whose text is the reaction emoji (translated to unicode
for common names), keeping the downstream auth gate, thread-context
fetch, dedup, and skill routing unchanged.

- Self-reactions and non-message items are dropped; reactions on
  messages not sent by this bot are dropped (Feishu-adapter parity).
- The reacted-to message's thread parent becomes the synthesized
  thread_ts so the reaction lands in the same session as a reply would.
- Manifest gains reactions:read scope + reaction_added bot event.

Salvaged from PR #29916 by @bpross.
Related: #33111, #44508, #45265 (same cluster).
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1 @johnkattenhorn
@Kev-fs @harrisonmedmedmetrics
feat(slack): opt-in reaction triggers, removed events, hooks, channel…
558dab0 
… handoff

Build the full reaction pipeline on top of the #29916 base:

- Opt-in gate: slack.reaction_triggers (default OFF — reaction events
  stay acked-and-dropped so busy channels don't wake the agent on every
  emoji). 'true' routes reactions on the bot's OWN messages; an explicit
  emoji-name list routes those emojis from any message (handoff flows).
- reaction_removed events now route too, distinguished by the
  cross-platform text convention reaction:added:<emoji> /
  reaction:removed:<emoji> (matches the Feishu and Photon adapters, so
  agents and skills see one shape everywhere).
- Authorization: the reactor becomes the synthesized message's user, so
  the early _is_user_authorized gate and allowed_channels whitelist
  apply exactly as for typed messages. _hermes_force_process only skips
  the mention requirement (a reaction on the bot's own message is
  definitionally addressed to the bot), mirroring Feishu/Photon.
- Gateway hooks (#33111 by @johnkattenhorn): every human reaction on a
  message item fires reaction:added / reaction:removed through the new
  BasePlatformAdapter.set_reaction_handler → GatewayRunner
  ._handle_reaction_event → HookRegistry.emit, independent of the
  routing opt-in. Documented in hooks.md.
- Channel handoff (#45265 by @Kev-fs): slack.reaction_trigger_target
  routes the reaction turn to a configured channel (top-level via
  _hermes_no_thread_response + reply-anchor suppression in
  gateway/platforms/base.py) or C123:<ts> thread.
- Manifest: reaction_removed event subscription added alongside
  reaction_added/reactions:read.
- Docs: slack.md Reaction Triggers section; hooks.md event table rows.

Also credits #44508 by @harrisonmedmedmetrics (inbound reaction_added
handling — same plumbing class, superseded by this consolidated shape).

Co-authored-by: johnkattenhorn <john.kattenhorn.personal@gmail.com>
Co-authored-by: Kev-fs <kevin@fleetsmarts.net>
Co-authored-by: harrisonmedmedmetrics <harrison@medmetricsrx.com>
teknium1 added a commit that referenced this pull request Jul 23, 2026
@teknium1
chore(release): map C17 reaction-cluster contributor emails
1f25791 
- john.kattenhorn.personal@gmail.com -> johnkattenhorn (#33111)
- harrison@medmetricsrx.com -> harrisonmedmedmetrics (#44508)
- kevin@fleetsmarts.net -> Kev-fs (#45265)
@teknium1

teknium1 commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Closing as superseded by #70195 (merged): covered by the consolidated pipeline landed in #70195, Co-authored-by credit included.

Thanks for the work — it's credited in #70195's summary.

@teknium1 teknium1 closed this Jul 23, 2026
randlee pushed a commit to randlee/hermes-agent that referenced this pull request Aug 11, 2026
@bpross @teknium1
fix(slack): forward reaction_added events to the message pipeline
0e6cdf2 
Slack reaction_added events were explicitly acked and dropped, so a user
reacting to a bot message (👍 to approve, ✅ to acknowledge) produced
nothing. Forward them through the normal message pipeline as synthesized
MessageEvents whose text is the reaction emoji (translated to unicode
for common names), keeping the downstream auth gate, thread-context
fetch, dedup, and skill routing unchanged.

- Self-reactions and non-message items are dropped; reactions on
  messages not sent by this bot are dropped (Feishu-adapter parity).
- The reacted-to message's thread parent becomes the synthesized
  thread_ts so the reaction lands in the same session as a reply would.
- Manifest gains reactions:read scope + reaction_added bot event.

Salvaged from PR NousResearch#29916 by @bpross.
Related: NousResearch#33111, NousResearch#44508, NousResearch#45265 (same cluster).
randlee pushed a commit to randlee/hermes-agent that referenced this pull request Aug 11, 2026
@teknium1 @johnkattenhorn
@Kev-fs @harrisonmedmedmetrics
feat(slack): opt-in reaction triggers, removed events, hooks, channel…
6499540 
… handoff

Build the full reaction pipeline on top of the NousResearch#29916 base:

- Opt-in gate: slack.reaction_triggers (default OFF — reaction events
  stay acked-and-dropped so busy channels don't wake the agent on every
  emoji). 'true' routes reactions on the bot's OWN messages; an explicit
  emoji-name list routes those emojis from any message (handoff flows).
- reaction_removed events now route too, distinguished by the
  cross-platform text convention reaction:added:<emoji> /
  reaction:removed:<emoji> (matches the Feishu and Photon adapters, so
  agents and skills see one shape everywhere).
- Authorization: the reactor becomes the synthesized message's user, so
  the early _is_user_authorized gate and allowed_channels whitelist
  apply exactly as for typed messages. _hermes_force_process only skips
  the mention requirement (a reaction on the bot's own message is
  definitionally addressed to the bot), mirroring Feishu/Photon.
- Gateway hooks (NousResearch#33111 by @johnkattenhorn): every human reaction on a
  message item fires reaction:added / reaction:removed through the new
  BasePlatformAdapter.set_reaction_handler → GatewayRunner
  ._handle_reaction_event → HookRegistry.emit, independent of the
  routing opt-in. Documented in hooks.md.
- Channel handoff (NousResearch#45265 by @Kev-fs): slack.reaction_trigger_target
  routes the reaction turn to a configured channel (top-level via
  _hermes_no_thread_response + reply-anchor suppression in
  gateway/platforms/base.py) or C123:<ts> thread.
- Manifest: reaction_removed event subscription added alongside
  reaction_added/reactions:read.
- Docs: slack.md Reaction Triggers section; hooks.md event table rows.

Also credits NousResearch#44508 by @harrisonmedmedmetrics (inbound reaction_added
handling — same plumbing class, superseded by this consolidated shape).

Co-authored-by: johnkattenhorn <john.kattenhorn.personal@gmail.com>
Co-authored-by: Kev-fs <kevin@fleetsmarts.net>
Co-authored-by: harrisonmedmedmetrics <harrison@medmetricsrx.com>
randlee pushed a commit to randlee/hermes-agent that referenced this pull request Aug 11, 2026
@teknium1
chore(release): map C17 reaction-cluster contributor emails
c3b983c 
- john.kattenhorn.personal@gmail.com -> johnkattenhorn (NousResearch#33111)
- harrison@medmetricsrx.com -> harrisonmedmedmetrics (NousResearch#44508)
- kevin@fleetsmarts.net -> Kev-fs (NousResearch#45265)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@teknium1 teknium1 teknium1 left review comments

Assignees

No one assigned

Labels

comp/gateway Gateway runner, session dispatch, delivery P3 Low — cosmetic, nice to have platform/slack Slack app adapter sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:risk-security-boundary Sweeper risk: may affect sandboxing, auth, credentials, or sensitive data type/feature New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@harrisonmedmedmetrics @teknium1 @alt-glitch