I encountered a similar problem recently while migrating an old app. It modeled IDs as 64-bit BIGINT columns (a decision made in the 2000s) and populated them with MySQL’s UUID_SHORT function. This worked fine for over a decade until we migrated to a different MySQL system and started getting conflicts for IDs already existing or not being able to find a row which had just been inserted.

They’d missed the part that UUID_SHORT() returns an unsigned integer and created the column as the default signed integer. MySQL uses an algorithm where the top n bits are based on the server ID, which worked on the old server which had id=1 and never returned a number where the first bit was 1. The new cluster fortunately always did so the problem was immediately identified, but it was confused by one of those bonus MySQL data-destruction features – the way it silently truncated data meant that it was silently truncating new IDs to the same value but the logged value wasn’t in the database at all.