The issue is not specific to the queue pattern used in the implementation, it mostly allowed us to catch it early. We could have encountered it elsewhere: we are using explicit locks of the set of the same set of features with FOR SHARE in the FTS plugins (see request #35872). This something we should do more because we have similar (but less visible due to less activity) issues in multiple parts of Tuleap. There is a blogpost from Frank de Jonge doing an (semi-)high level explanation on this very topic: https://blog.frankdejonge.nl/ensuring-consistency-during-concurrent-requests/

For the queue implementation itself: it is a new "trick" for us because we had to support MySQL 5.7 but others have implemented variant of it for quite some times now, Symfony Messenger has a 5 years old implementation based on the FOR UPDATE usage.

For sure, we cannot consider that all the DB servers speaking the MySQL protocol will work fine without proper testing but it's a global issue that is not specific to the queue implementation. The issue we have seen when trying to run our test suites on MariaDB 10.6 (gerrit #27898) is another proof of that. That's said in both cases it is caused by something I wrote...

Shouldn't we be more cautious about this ?

The fact is that we don't know exactly what we have on the field as databases. I see two potential problems:

• A futur version of MySQL introduce the same kind of regression seen on Percona
• There is a much more diverse db landscape and the "other mysql versions" have the same kind of issues

WDYT ?