MySqlConnector.MySqlException: Incorrect string value: '\xF0\x9F\x98\x82 h...' for column 'title_unicode' at row 1

[ppy-sentryintegration]

Sentry Issue: OSU-SERVER-BEATMAP-SUBMISSION-R

MySqlConnector.MySqlException: Incorrect string value: '\xF0\x9F\x98\x82 h...' for column 'title_unicode' at row 1
  File "/_/src/MySqlConnector/Core/ServerSession.cs", line 885, in async ValueTask<PayloadData> ServerSession.ReceiveReplyAsync(IOBehavior ioBehavior, CancellationToken cancellationToken)
  File "/_/src/MySqlConnector/Core/ResultSet.cs", line 37, in async Task ResultSet.ReadResultSetHeaderAsync(IOBehavior ioBehavior)
  File "/_/src/MySqlConnector/MySqlDataReader.cs", line 130, in void MySqlDataReader.ActivateResultSet(CancellationToken cancellationToken)
  File "/_/src/MySqlConnector/MySqlDataReader.cs", line 482, in async Task MySqlDataReader.InitAsync(CommandListPosition commandListPosition, ICommandPayloadCreator payloadCreator, IDictionary<string, CachedProcedure> cachedProcedures, IMySqlCommand command, CommandBehavior behavior, Activity activity, IOBehavior io...
  File "/_/src/MySqlConnector/Core/CommandExecutor.cs", line 56, in async ValueTask<MySqlDataReader> CommandExecutor.ExecuteReaderAsync(CommandListPosition commandListPosition, ICommandPayloadCreator payloadCreator, CommandBehavior behavior, Activity activity, IOBehavior ioBehavior, CancellationToken cancellationToken)
...
(22 additional frame(s) were not displayed)

[bdach]

>>> str(b'\xf0\x9f\x98\x82', 'utf-8')
'😂'

Obnoxiousness aside, I'm not sure why this would die provided it seems to be correctly placed in the unicode field. I wrote a test for it and it doesn't fail on docker, which may indicate this is some collation curiosity on production.

@peppy non-urgent, what are your thoughts on this in general? should I be forbidding people from putting emoji specifically in metadata? maybe a wider array of characters too? (depends on what production db is configured to which I have no way to check)

[nanaya]

if you're relying on osu-web's database, the migration excluded utf8(mb3/4) declarations but production still has a bunch of columns with utf8mb3 (aka fake utf8) charset

[peppy]

I think we should probably fix the prod database in these cases.