One of our email handlers picked up something containing an emoji which the database behind JIRA can't handle (as detailed here https://community.atlassian.com/t5/Jira-questions/Jira-fails-to-import-an-email-with-the-emoji/qaq-p/752162). Every minute the handler fires, increments the issue number for the project, and then fails, so our issue numbers are rapidly increasing. The email responsible is no longer within the inbox being processed, so we're assuming it must be cached somewhere for the handler to keep finding it. Can anyone advise what we would need to do to get rid of the message?
We've tried restarting the system and manually removing the contents of the cache folder (which caused other issues, so had to be restored).
In my experience, once you remove the email containing this kind of character from the inbox Jira is checking that is all it takes to stop Jira trying to process this message.
There is also another problem here, because even if we eliminate this first message, your system is still vulnerable to suffer this same problem the next email that Jira processes containing such a character.
I understand if you only want to troubleshoot this single message problem, I'm happy to try to help only in that way if you like. However the source of this problem is that mysql databases can't store 4-byte characters (such as those used by emojis). One sure-fire way to both correct this problem and prevent it again in the future would be to migrate your Jira data into a different database type that does not suffer this problem, such as Postgresql or Microsoft's SQL server. Steps on how to do this are in Switching databases. If you can't switch databases, AND you are using a MySQL 5.7.x, and a Jira version 7.3 or higher, then you could follow a specific work-around in https://confluence.atlassian.com/jirakb/emojis-and-special-characters-for-jira-with-mysql-952604493.html
This guide explains how you can use the utf8mb4 encoding to allow mysql to properly store these kinds of characters and both fix this problem and prevent it again.
We honestly have no idea why it kept processing after the removal of the email, but deleting and recreating the handler stopped the issue. We have since implemented db changes to allow 4-byte characters, thanks for pointing us at that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.