[random test failure] CommentUserNameTest::testUsername() random failure

With 5000 runs without a failure this one is too random for me, I think you might have hit a fluke there @catch.

This one seems to fail consistently on PostgreSQL as far as I can see; I've reproduced the failure manually with postgres:16 (in ddev).

mcdruid@drupal-10:/var/www/html$ git status
Refresh index: 100% (18217/18217), done.
On branch 11.x
Your branch is up to date with 'origin/11.x'.

mcdruid@drupal-10:/var/www/html$ vendor/phpunit/phpunit/phpunit -c core core/modules/comment/tests/src/Kernel/Views/CommentUserNameTest.php
PHPUnit 10.5.35 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.3.10
Configuration: /var/www/html/core/phpunit.xml.pgsql

E                                                                   1 / 1 (100%)

Time: 00:02.411, Memory: 4.00 MB

There was 1 error:

1) Drupal\Tests\comment\Kernel\Views\CommentUserNameTest::testUsername
Error: Call to a member function access() on null

...snip...

Not sure how helpful this will be, but debugging MySQL and PostgreSQL side by side, this seems to be where it goes wrong for postgres:

\Drupal\Core\TypedData\DataReferenceDefinition::getTargetDefinition successfully finds a targetDefinition in MySQL but that property doesn't seem to be set in Postgres AFAICS.

I'm not sure why.

The stack is:

DataReferenceDefinition.php:49, Drupal\Core\TypedData\DataReferenceDefinition->getTargetDefinition()
EntityReference.php:52, Drupal\Core\Entity\Plugin\DataType\EntityReference->getTargetDefinition()
EntityReference.php:73, Drupal\Core\Entity\Plugin\DataType\EntityReference->getTarget()
DataReferenceBase.php:37, Drupal\Core\TypedData\DataReferenceBase->getValue()
FieldItemBase.php:154, Drupal\Core\Field\FieldItemBase->__get()
FieldItemList.php:116, Drupal\Core\Field\FieldItemList->__get()
Comment.php:356, Drupal\comment\Entity\Comment->getCommentedEntity()
CommentAccessControlHandler.php:36, Drupal\comment\CommentAccessControlHandler->checkAccess()
EntityAccessControlHandler.php:109, Drupal\Core\Entity\EntityAccessControlHandler->access()
ContentEntityBase.php:738, Drupal\Core\Entity\ContentEntityBase->access()
EntityAccessCheck.php:68, Drupal\Core\Entity\EntityAccessCheck->access()
AccessManager.php:160, call_user_func_array:{/var/www/html/core/lib/Drupal/Core/Access/AccessManager.php:160}()
AccessManager.php:160, Drupal\Core\Access\AccessManager->performCheck()
AccessManager.php:136, Drupal\Core\Access\AccessManager->check()
AccessManager.php:93, Drupal\Core\Access\AccessManager->checkNamedRoute()
Url.php:813, Drupal\Core\Url->access()
StringFormatter.php:132, Drupal\Core\Field\Plugin\Field\FieldFormatter\StringFormatter->viewElements()
FormatterBase.php:91, Drupal\Core\Field\FormatterBase->view()
EntityViewDisplay.php:268, Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple()
EntityFieldRenderer.php:257, Drupal\views\Entity\Render\EntityFieldRenderer->buildFields()
EntityFieldRenderer.php:143, Drupal\views\Entity\Render\EntityFieldRenderer->render()
EntityField.php:869, Drupal\views\Plugin\views\field\EntityField->getItems()
FieldPluginBase.php:1195, Drupal\views\Plugin\views\field\FieldPluginBase->advancedRender()
views.theme.inc:231, template_preprocess_views_view_field()
ThemeManager.php:261, call_user_func_array:{/var/www/html/core/lib/Drupal/Core/Theme/ThemeManager.php:261}()
ThemeManager.php:261, Drupal\Core\Theme\ThemeManager->render()
Renderer.php:446, Drupal\Core\Render\Renderer->doRender()
Renderer.php:203, Drupal\Core\Render\Renderer->render()
FieldPluginBase.php:1796, Drupal\views\Plugin\views\field\FieldPluginBase->theme()
StylePluginBase.php:769, Drupal\views\Plugin\views\style\StylePluginBase->elementPreRenderRow()
DoTrustedCallbackTrait.php:107, call_user_func_array:{/var/www/html/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php:107}()
DoTrustedCallbackTrait.php:107, Drupal\Core\Render\Renderer->doTrustedCallback()
Renderer.php:825, Drupal\Core\Render\Renderer->doCallback()
Renderer.php:387, Drupal\Core\Render\Renderer->doRender()
Renderer.php:203, Drupal\Core\Render\Renderer->render()
Renderer.php:120, Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure:/var/www/html/core/lib/Drupal/Core/Render/Renderer.php:119-121}()
Renderer.php:593, Drupal\Core\Render\Renderer->executeInRenderContext()
Renderer.php:119, Drupal\Core\Render\Renderer->renderInIsolation()
StylePluginBase.php:711, Drupal\views\Plugin\views\style\StylePluginBase->renderFields()
StylePluginBase.php:574, Drupal\views\Plugin\views\style\StylePluginBase->renderGrouping()
StylePluginBase.php:462, Drupal\views\Plugin\views\style\StylePluginBase->render()
DisplayPluginBase.php:2177, Drupal\views\Plugin\views\display\DisplayPluginBase->render()
ViewExecutable.php:1592, Drupal\views\ViewExecutable->render()
DisplayPluginBase.php:2467, Drupal\views\Plugin\views\display\DisplayPluginBase->preview()
ViewExecutable.php:1721, Drupal\views\ViewExecutable->preview()
CommentUserNameTest.php:158, Drupal\Tests\comment\Kernel\Views\CommentUserNameTest->testUsername()

Looks like the test fail that @catch originally flagged up was under PostgreSQL:

SIMPLETEST_DB = pgsql://drupaltestbot:drupaltestbotpw@database/drupaltestbot?module=pgsql

I think this is critical as it affects consistently tests on PostgreSql

Just ran into this as well. https://git.drupalcode.org/issue/drupal-3343634/-/pipelines/320105/test_...

This is consistently reproducible locally... in fact it's less random and much more like, totally broken.

The test is set up wrong. Fixed test MR proposed.

All green on pgsql.

https://git.drupalcode.org/issue/drupal-3479887/-/pipelines/321059/

bradjones1 → changed the visibility of the branch 3479887-random-test-failure to hidden.

Looks good to me.

@bradjones1 and I discussed this on the weekend, this is the correct fix

Committed to 11.x

Doesn't apply to 11.0.x but I think we should backport this all the way back to 10.3.x

Tagging as 'Patch (to be ported)' as a result

larowlan → closed merge request !9954

I'd be curious to know why this only failed on pgsql given the fix, and not on mysql and sqlite

The default target of an entity reference field is the user entity. Comment::bundleFieldDefinitions sets this to the entity type configured on the comment type
In this test it was not being set because the comment type wasn't created
As a result the commented entity was loaded as a user
On MySQL/sqlite it was entity id 1, on pgsql it was 2
This should have been loading an entity test entity, but instead was loading a user
User 1 existed, user 2 did not

Kudos to bradjones1 for working out it was loading the wrong entity type, at the weekend I pointed him towards why on slack

Added MRs all the way back to 10.2.x

Funny almost all MRs have random failures but none appear to be around this test.

Makes sense to backport this all the way back to 10.2.x

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.