- Issue created by @bkline@rksystems.com
We have a moderate-sized Drupal 10 application for which there are a few dozen phpunit test scripts, and for a long time all of the tests passed successfully every time they were run. In the process of preparing a release of the application which will move the site from Drupal 10.1.1 to Drupal 10.2.4, we saw that three of our tests had started failing. On inspection, we realized that the three test scripts involved in the failures were all for Functional tests, and in fact, they were the only Functional test scripts in the test suite. We found that running those tests using MySQL instead of SQLite eliminated the failures. However, we are unable to run all of the tests in the suite using MySQL, because some of the SQL queries created by the Entity Query API are so complex that—although they run successfully under MySQL when performing the same operations in the live site, and also run successfully in the tests when running under SQLite—the queries hang forever when running under phpunit with MySQL (another day, another bug report). We also discovered that if we convert the Functional tests to FunctionalJavascript tests they succeed every time. So our workaround will be to convert these three test scripts from Functional to FunctionalJavascript tests, even though those tests would not otherwise require the additional functionality provided by FunctionalJavascript tests. We're reporting the problem here even though we have a workaround, in case the core development team is interested in tracking down and eliminating the case of the problem. Even if they decide tackling a bug report with such a large "repro case" is too daunting, it will have been worth it if this report saves anyone else who runs into this problem from pulling out all of his or her hair. 😅
Again, these tests ALWAYS passed before as Functional tests.
Unfortunately, we were unable to reproduce the problem in a tiny site. The best we could do was to add a small repro module to our own code base. This module is completely decoupled from any of our other modules, but without those modules being present the Functional test in the repro module passes. The best theory we can come up with is that the failures are only triggered when Drupal and/or Symfony have to do enough scanning/parsing of other modules, doing some unspecified work in the database to remember what they saw. We have seen clues that—at least for some conditions—Drupal and/or phpunit are caching SQLite database writes in memory up to a certain threshold, and perhaps that threshold isn't reached if our repro case is too tiny (but that's wild speculation at best).
These repro instructions assume a host development machine with git, docker, php, and composer.
On the host machine:
In the container:
./run-tests.sh
The error messages we get vary. Some examples:
PDOException: SQLSTATE[HY000]: General error: 10 disk I/O error
GuzzleHttp\Exception\RequestException: cURL error 1: Received HTTP/0.9 when not allowed
PDOException: SQLStATE[HY000]: General error: 11 database disk image is malformed
Occasionally (but not often) the first (Functional) test will succeed. In that case (still in the container) repeat ./run-tests.sh.
As noted above, the second (FunctionalJavascript) test always succeeds. Other than the test type, the two tests are identical.
Determine and resolve the cause of the test failures.
None.
None.
None.
Regression fixed in Functional tests.