Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Rules has some new automated testing failures with the error "Creating default object from empty value". The failing tests are all Kernel tests:
Kernel/Engine/MetadataAssertionTest.php:76 (testAssertingEntityBundle)
Kernel/Engine/MetadataAssertionTest.php:114 (testAssertingWithLogicalOperations)
Kernel/Engine/MetadataAssertionTest.php:153 (testAssertingOfNegatedConditions)
Kernel/Engine/AutocompleteTest.php:64 (testAutocomplete)
Kernel/Engine/AutocompleteTest.php:89 (testNodeAutocomplete)
Kernel/Engine/AutocompleteTest.php:352 (testListAutocomplete)
Kernel/RulesEngineTest.php:107 (testProvidedVariables)
The backtrace for each failure is the same:
Backtrace:
/var/www/html/core/modules/user/src/ContextProvider/CurrentUserContext.php:55
/var/www/html/core/modules/user/src/ContextProvider/CurrentUserContext.php:73
/var/www/html/core/lib/Drupal/Core/Plugin/Context/LazyContextRepository.php:97
/var/www/html/modules/contrib/rules/src/Engine/ExecutionMetadataState.php:43
/var/www/html/modules/contrib/rules/src/Engine/ExecutionMetadataState.php:31
/var/www/html/modules/contrib/rules/src/Engine/RulesComponent.php:293
/var/www/html/modules/contrib/rules/src/Engine/RulesComponent.php:342
which leads back to modules/user/src/ContextProvider/CurrentUserContext.php:55. However, I can replicate these same failures locally and I get an extra file in the backtrace list after(before) CurrentUserContext.php which is vendor/symfony/phpunit-bridge/DeprecationErrorHandler.php:267
The failures started on 8th Jan 2018 (all OK up to 7th). No rules code has been committed from 14 Dec so the failures are probably due to a Core change. The error is the same in core 8.5 amd 8.6. Interestingly this fault spanned the period when the testing version switched from 8.5 to 8.6 on 13th January. Core 8.4 has no failures and runs OK. This shows the value of having daily testing #2927534: More automated test runs on drupal.org
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | tests fail from 8 Jan.png | 204.98 KB | jonathan1055 |
Comments
Comment #2
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedLine 55 of
core/modules/user/src/ContextProvider/CurrentUserContextisThe referenced issue #2934192: FieldItemBase::getValue() returns partial or full values depending on state refers back to #2671964: ContextHandler cannot validate constraints which has a commit on 7th Jan which adds the lines above. So that looks like the reason for our sudden test failures.
Comment #3
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedThe Rules tests fail from Jan 8th, the day after the Core commit to /modules/user/src/ContextProvider/CurrentUserContext.php
Comment #4
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedThere is now a core issue to fix this problem
#2936642: Getting runtime contexts will generate an E_WARNING for anonymous users
Comment #5
fagothx. So we have to wait for the core fix to be committed.
Comment #6
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commented#2936642: Getting runtime contexts will generate an E_WARNING for anonymous users has been committed so the Rules tests are no longer failing with this fault.
However, in #2936642-12: Getting runtime contexts will generate an E_WARNING for anonymous users tim.plunkett says
All six tests create a rule using $this->expressionManager->createRule()
Five of the six add context using addContextDefinition() and the sixth one uses ContextConfig::create()
But it appeaars that these do not actually cause the fault. The error is triggered when calling the ->checkIntegrity() or ->autocomplete() methods.
It would be useful to know if the Rules tests are making incorrect assumptions, as that may cause us other problems that we have not yet seen.
Comment #7
TR CreditAttribution: TR commented@tim.plunkett says:
Well, @tim.plunkett's assertion is a little glib. Apparently, the truth of the matter is that the user module makes certain assumptions that must be satisfied for user to work properly. Specifically, user needs the presence of AT LEAST ONE user entity in the database. That is an additional requirement that's not true of other core modules like node - node will run just fine without any nodes in the database.
But the user module ASSUMES that there will always be an anonymous user, and if it's not there we get this test failure.
This is a problem for Kernel tests, because in Kernel tests modules aren't fully installed. Rules tests load the user module and install the user Entity schema, and for all other core modules (again, like node) that's enough. But for the user module we really have to completely install it.
Fortunately this is a simple fix - in short, we just call
user_install()which sets up the anonymous user and the admin user.There are other ways to do this - we could explicitly do a
User::create()to create an anonymous user, for instance, but I think we should just calluser_install()and leave it to the user module to do whatever it thinks is necessary: If that 'whatever' changes in the future, we will still be protected as long as we just calluser_install(). I'm going to close this issue and let this fix be handled in #2989417: Argument 1 passed to \EntityContext::fromEntity() must implement EntityInterface because that's the current problem we're having.@jonathan1055 says:
If assuming the user module should be initialized in Kernel tests the same way as every other core module is an 'incorrect assumption', then sure, guilty as charged. But I think it's more accurate to characterize this as a case where the user module requires a special, undocumented initialization in order to provide its internal functions (initializing the current user context) without error. To me, the real problem is that the user module makes an assumption about the presence of an anonymous user, whereas it could just as easily operate without that assumption and without the accompanying error (as it had been doing until #2932462: Add EntityContextDefinition for the 80% use case was committed).