regression: outgoing webhooks fail to match emoji trigger words

Closed
AB
2d ago
+9-2

Proposed changes (including videos or screenshots)

Outgoing webhooks that use an emoji shortcode as their trigger word (for example :smile:) stopped firing in 8.7.

The reason: since 8.7 the message composer saves emojis as their native Unicode character (😄) instead of the :smile: text. The outgoing-webhook matcher compares the configured trigger word against the raw message text, so :smile: no longer appeared anywhere in the message and the webhook silently never ran. This worked in 8.6, where the message was stored as :smile:.

This change makes the trigger matcher recognize both forms. For each configured trigger word it now also checks the word's native Unicode emoji equivalent, so a :smile: trigger matches whether the message contains :smile: (e.g. sent via API) or 😄 (sent from the composer). It reuses the same shortcode-to-unicode conversion the message pipeline already uses.

https://github.com/user-attachments/assets/3abc0561-8fa8-4a2c-9333-9bbc3875c142

Issue(s)

CORE-2469 (no GitHub issue).

Steps to test or reproduce

  1. Create an incoming webhook that posts to a channel, e.g. #emoji-webhook-results.
  2. Create an outgoing webhook on another channel #emoji-webhook-source: event Message Sent, Trigger Words :smile:, Word Placement Anywhere On, URL set to the incoming webhook's URL.
  3. Open #emoji-webhook-source, type hello and pick the 😄 emoji from the picker/autocomplete, then send it.
  4. Expected: the message is forwarded and appears in #emoji-webhook-results. (Before this fix, nothing appeared.)

Further comments

CORE-2469

Summary by CodeRabbit

  • Bug Fixes
    • Trigger-based integrations now recognize Unicode equivalents of configured trigger words.
    • Preserved trigger matching behavior for words appearing at the beginning or anywhere in a message.
    • Recorded trigger data consistently using the configured trigger word.