Generated with the help of an LLM.

Problem/Motivation

Functional tests fail at random with a missing cache_file_parsing table. The daily PostgreSQL 18 pipeline on main has failed on this every day since 2026-10-28.

SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "public.test62018227cache_file_parsing" does not exist
SQLSTATE[HY000]: General error: 1 no such table: test67007309.cache_file_parsing

Failing jobs:

ConfigImportCommandTest fails most often. Its setUp() calls copyConfig(), which reaches DatabaseBackend::invalidateMultiple() through FileStorage and CacheCollector. Other failures reach the bin through YamlRouteDiscovery and FileParsingCacheCollectorBase.

DatabaseBackend::catchException() rethrows the exception when tableExists() returns TRUE at the time of the check.

The daily PostgreSQL pipeline passed on 2026-10-20 and was skipped from 2026-10-21 to 2026-10-27. #3082239 changed pgsql/Schema.php on 2026-10-27.

Steps to reproduce

Run the functional test suite on PostgreSQL in CI. The failing test changes between runs.

Proposed resolution

To be determined.

Remaining tasks

  • Find the cause.
  • Fix it.

Issue fork drupal-3634917

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

joelpittet created an issue. See original summary.

joelpittet opened merge request !17660

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Status: Active » Needs review

Generated with the help of an LLM.

The installer uses MemoryBackend for cache.file_parsing. After installation, there is no cache_file_parsing table.

BrowserTestBase::initFrontPage() sends a request to the site. The site writes its cache collectors after it sends the response. At the same time, the test runner continues. The site write fails, and the site makes the table. In the test runner, a query fails before the table is there. Then tableExists() returns TRUE, and DatabaseBackend throws the exception again.

Process ID logs show this sequence for each local failure. On PostgreSQL 18.6, all 6 ConfigImportCommandTest methods fail in a single run. With concurrency 8, 5 of 48 methods fail. On a36bfd1a715, the parent of #3082239: Forbid limited length primary and unique keys, allow only in indexes, 4 of 6 methods fail. #3594338: Add a command to import configuration added ConfigImportCommandTest on 2026-10-27.

In DatabaseBackend, these methods now do a failed query again if the table is there: setMultiple(), invalidateMultiple(), deleteMultiple() and deleteAll(). A second failure goes to the caller. The new kernel test makes the table in a StatementExecutionFailureEvent listener. Without the fix, the test fails on PostgreSQL and SQLite. With the fix, 48 of 48 methods pass on both.

smustgrave’s picture

smustgrave commented

So looking at the MR this one actually uncovered a real bug then? May not be random test failure category now.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

@smustgrave it appeared random when I ran into it, I re-ran the job a few times and lucked out and got it through.

mondrake’s picture

mondrake
Location 🇮🇹
commented
Related issues: +#3622582: Cleanup database exceptions, +#2371709: Move the on-demand-table creation into the database API, +#3568040: [PP-1] Convert *Storage() classes' ensureTableExists methods to use SchemaDefinition objects

In my flow, I would first do #3622582: Cleanup database exceptions, the test failure in pgsql would remain, but that one would do neither better nor worse, then do #2371709: Move the on-demand-table creation into the database API, then #3568040: [PP-1] Convert *Storage() classes' ensureTableExists methods to use SchemaDefinition objects.

mondrake’s picture

mondrake
Location 🇮🇹
commented

btw the first two are criticals, and that is now more substantive

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Priority: Normal » Critical

Following the pattern or marking these critical

mondrake’s picture

mondrake
Location 🇮🇹
commented

C/P myself from Slack re #6,

it looks like I cut too short on the comment and then I realize I may have spoiled the issue. Yes in general that sequence should be able to solve the issue at hand in a way more reliable in the long term. If I understand correctly, #3634917: [random test failure] “cache_file_parsing” table does not exist in functional tests on PostgreSQL and SQLite is a race condition on the table creation, and #2371709: Move the on-demand-table creation into the database API in its MR 17366 should minimize that, so that once DatabaseBackend gets converted, then maybe that’s enough and #3634917: [random test failure] “cache_file_parsing” table does not exist in functional tests on PostgreSQL and SQLite is not needed after all. But that may be taking too long, and needs to prove right.

mondrake’s picture

mondrake
Location 🇮🇹
commented
Status: Needs review » Reviewed & tested by the community

LGTM. Can we try re-running the failed SQLite job, and the mysqli pipeline too?

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Thanks and yes I will have rerun the failed job

  • catch committed c730ea9a on 11.5.x 
    fix: #3634917 [random test failure] “cache_file_parsing” table does not...

  • catch committed 8b1ecd65 on 11.x 
    fix: #3634917 [random test failure] “cache_file_parsing” table does not...

  • catch committed 0b97ba29 on 12.0.x 
    fix: #3634917 [random test failure] “cache_file_parsing” table does not...

  • catch committed e28908b6 on main 
    fix: #3634917 [random test failure] “cache_file_parsing” table does not...
catch’s picture

catch
he/him
Primary language English
commented
Version: main » 11.5.x-dev
Status: Reviewed & tested by the community » Fixed

I ran the mysqli pipeline but forgot to post back here.

Agreed we should get this in, the test coverage should help to ensure that the lazy table consolidation doesn't regress it too.

Committed/pushed to main and cherry-picked back through to 11.5.x, thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.