Existing emoji tags appear as new in the composer; new emoji tags disappear after posting

Contribute Bug

AI-generated summary

scavin reports a bug in the topic composer where existing emoji tags are incorrectly displayed as new (showing a “Create” option instead of usage counts), while genuinely new emoji tags disappear after posting. The issue is reproducible on main and stems from DiscourseTagging.clean_tag, which strips emoji characters during search, causing the system to fall back to popular tags or fail to match existing records.

The user provides a patch that preserves complete emoji graphemes using existing Emoji.unicode_replacements data, ensuring accurate tag matching and saving without adding database migrations or frontend changes. The fix also improves disabled-tag suggestions for names starting with emojis. Local validation confirmed 572 backend and 8 browser test cases passed, verifying that existing tags retain their counts and new tags persist correctly. The patch is available on a GitHub branch and addresses specific composer failures, though it does not resolve all historical emoji-tag limitations.

1

I found inconsistent behavior with emoji tags in the topic composer and reproduced it on unmodified main at 802125b979b5bb848a7cfc52409ef3176ffd4d82.

For an existing emoji tag, typing its name can show Create instead of the existing tag and its usage count. Selecting that option and posting still attaches the existing tag. A genuinely new emoji tag is a separate case: it can be selected in the composer, but disappears after posting.

To reproduce the existing-tag issue:

  1. Use a site with an existing emoji tag, such as 😊, and other, more frequently used tags.
  2. Open the topic composer and enter the emoji tag name.
  3. If that tag is outside the returned popular-tag limit, the dropdown shows a creation option and unrelated popular tags, without the existing tag’s usage count.
  4. Select the creation option, publish, and refresh. The topic still uses the original tag record.

In an isolated browser test, I used an existing emoji tag with a count of 17, an unrelated tag with a count of 100, and a search limit of 1. The dropdown showed Create: '😊' and popular x100; after posting, the existing emoji tag was correctly reused. With no existing 😊 record, the same operation returned HTTP 200 but saved no tag.

The cause is in DiscourseTagging.clean_tag, which is used for both search terms and saving new names. It removes emoji characters. Search then falls back to popular results, while saving can still find an existing tag by its original name before cleaning new names.

I have a small patch that preserves complete emoji graphemes recognized by the existing Emoji.unicode_replacements data. It keeps the existing ASCII filtering and removes invalid characters from non-emoji text. It also lets disabled-tag suggestions match the start of a name, since the current word-boundary expression misses emoji-leading names such as 😊-restricted.

The patch changes two implementation files and adds regression coverage in three test files. It does not add a database migration, frontend changes, a new API, or another emoji cache.

Local validation: 572 related backend examples and 8 browser examples passed. The browser tests check that an existing emoji tag shows x17, and that both it and a genuinely new 😊 remain after publishing and refreshing.

Patch branch:

Related reports and discussion:

These reports describe earlier emoji-tag limitations. This patch addresses the composer search and saving failures reproduced above; it does not claim to resolve every emoji-tag issue.