Encontrei um comportamento inconsistente com tags de emoji no compositor de tópicos e o reproduzi no main não modificado em 802125b979b5bb848a7cfc52409ef3176ffd4d82.
Para uma tag de emoji existente, digitar seu nome pode exibir Criar em vez da tag existente e sua contagem de uso. Selecionar essa opção e publicar ainda anexa a tag existente. Uma tag de emoji genuinamente nova é um caso separado: ela pode ser selecionada no compositor, mas desaparece após a publicação.
Para reproduzir o problema da tag existente:
- Use um site com uma tag de emoji existente, como
😊, e outras tags usadas com mais frequência. - Abra o compositor de tópicos e insira o nome da tag de emoji.
- Se essa tag estiver fora do limite de tags populares retornadas, o menu suspenso exibe uma opção de criação e tags populares não relacionadas, sem a contagem de uso da tag existente.
- Selecione a opção de criação, publique e atualize. O tópico ainda usa o registro original da tag.
Em um teste isolado no navegador, usei uma tag de emoji existente com contagem de 17, uma tag não relacionada com contagem de 100 e um limite de busca de 1. O menu suspenso mostrou Criar: '😊' e popular x100; após publicar, a tag de emoji existente foi reutilizada corretamente. Sem um registro existente de 😊, a mesma operação retornou HTTP 200, mas nenhuma tag foi salva.
A causa está em DiscourseTagging.clean_tag, que é usado tanto para termos de busca quanto para salvar novos nomes. Ele remove caracteres de emoji. A busca então recorre aos resultados populares, enquanto o salvamento ainda pode encontrar uma tag existente pelo seu nome original antes de limpar os novos nomes.
Tenho um pequeno patch que preserva grafemas completos de emoji reconhecidos pelos dados existentes de Emoji.unicode_replacements. Ele mantém a filtragem ASCII existente e remove caracteres inválidos de texto não-emoji. Ele também permite que sugestões de tags desativadas correspondam ao início de um nome, já que a expressão atual de fronteira de palavra perde nomes iniciados por emoji, como 😊-restricted.
O patch altera dois arquivos de implementação e adiciona cobertura de regressão em três arquivos de teste. Ele não adiciona uma migração de banco de dados, alterações de frontend, uma nova API ou outro cache de emoji.
Validação local: 572 exemplos relacionados de backend e 8 exemplos de navegador passaram. Os testes de navegador verificam que uma tag de emoji existente mostra x17, e que tanto ela quanto um 😊 genuinamente novo permanecem após publicar e atualizar.
Atualização — 23 de outubro de 2026
A correção agora foi submetida como PR #44994: FIX: Preserve emoji tags during search and saving e está pronta para revisão.
O CI completo no meu fork passou: todos os 10 trabalhos da matriz de teste, linting e verificações de licença.
Para esta execução, usei um ramo de validação separado com a mesma correção e aumentei o tempo limite do trabalho de teste de 20/30 minutos para 90 minutos, pois a execução anterior atingiu o tempo limite no runner do fork. Os comandos de teste, a matriz e as asserções permaneceram inalterados. O ajuste do tempo limite não faz parte do PR upstream. O PR não foi mesclado; o CI upstream ainda aguarda aprovação dos mantenedores.
Ramo do patch:
Relatos e discussões relacionados:
Esses relatos descrevem limitações anteriores de tags de emoji. Este patch aborda as falhas de busca e salvamento no compositor reproduzidas acima; ele não afirma resolver todos os problemas de tags de emoji.