Potential MySQL Bug in GitHub Workflow with Different Fixture Scales

[Zang983]

Hello,

I'm currently training in Symfony and PHP, and I was tasked with creating fixtures and phpUnit tests for a project where the base code was provided. The final instruction was to execute these tests during a GitHub push.

For the first time, I set up a GitHub workflow to execute these tests.

Locally, all my tests pass without any issues, but when I push to GitHub, some tests fail.

The test that highlights this potential bug is the testShouldFilteredVideoGamesByTags() method in the tests/Functional/VideoGame/FilterTest.php file. Specifically, the first case, which should simply fetch the results of the first page without applying any filters.

The generated video games consistently follow the format "Jeu vidéo X," where X increments. The expected result is the first 10 entries. However, when I generate 50 fixtures (as I originally did for the project), the results start at "Jeu vidéo 26." The generated database seems correct and consistent, and the configuration should be the same as on my local machine, except that I currently work on Windows. Strangely enough, when using 500 fixtures (increasing test results by a factor of 10), all tests pass without issues.

I tried using Docker on my local machine and adjusting the MySQL image configuration to ensure identical settings. Of course, I initially suspected a problem in my test logic or fixture generation code, but the tests are simple, and the generated data is always consistent.

What makes me believe this issue warrants this post is that when switching to PostgreSQL, the issue disappears, and all tests pass without any problems.

I'm aware this may not necessarily be a bug and could simply be a configuration I missed. In that case, thank you in advance for your feedback!

You can find the relevant repository with two branches here: one that works with 500 fixtures and another that doesn't with 50:
https://github.com/Zang983/example-bug-cicd-mysql

[tianon]

Interesting! That's kind of a large reproducer though. Maybe you can isolate this to something (much) smaller so that folks can take a look and try to help debug easier? (I often find that trying to create a smaller reproducer can also help me find the bug, so it's possible that happens here too!)

From the perspective of https://github.com/docker-library/mysql, we don't do much more than package stock MySQL into an image, and we even (intentionally) keep our configuration tweaks as minimal as possible so that we're delivering an authentic upstream experience, so if there's a bug in MySQL here, it's probably an upstream one (and for reporting that, you'll definitely want a much smaller reproducer).

[Zang983]

I'm going to try to narrow the issue down to its simplest form with a minimal test where the bug is clearly visible. Since these are student projects, I have very few dependencies, so I assumed the logic would be simple and clear enough to share. But you're right—the code comes with its full context, and if I can reproduce the bug in isolation, it will be much more meaningful.

I'll make the necessary modifications on GitHub and follow up here. If it turns out the bug is directly related to MySQL, I'll report it upstream. Thanks for your response and for all the work you do!