Problem/Motivation
After updating my site from 8.6.x -> 8.7.x, all anonymous user traffic gets the following error:
The 'entity:user' context is required and not present.
All updates preformed as expected and I don't know why I am seeing these errors. I pulled down a version of 8.7.x and compared the two stack traces between the working 8.7.x and my updated site and found that ContentEntityStorageBase::getFromPersistentCache() returns null on my site while in 8.7.x it returns an anonymous user object. Here is the stack trace:
* `EntityConverter::convert()`
* `LazyContextRepository::getAvailableContexts()`
* `CurrentUserContext::getRuntimeContexts()`
* `EntityStorageBase::load()`
* `SqlContentEntityStorage::doLoadMultiple()`
* `ContentEntityStorageBase::getFromPersistentCache()`
This is due to no record in the users table for the anonymous user.
Proposed resolution
Add a hook_requirements() to check that there's a record for user 0 and warn the site administrator if not. There's already a page on Drupal.org with instructions on how to update: Restore the anonymous (user ID 0) user record
Remaining tasks
Write a patch
Review
Commit
User interface changes
When anonymous exists
No status message
Doesn't exist

API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #50 | 3057399-nr-bot.txt | 1.45 KB | needs-review-queue-bot |
| #48 | Screenshot 2024-02-09 at 13-50-42 Status report Drupal.png | 17.6 KB | quietone |
Issue fork drupal-3057399
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:
- 3057399-some-sites-are
changes, plain diff MR !5466
Comments
Comment #2
cilefen commentedThe same is mentioned here: #3052905-34: Failed while updating from 8.6.15 to 8.7.x: Update aborted by: menu_link_content_post_update_make_menu_link_content_revisionable
Comment #3
catchBumping this to critical - if it's a contrib module issue we can move it there, but given at least two people have hit this on upgrade we should narrow it down.
Comment #4
jimafisk commentedHere are some details about the state of things leading up to the error (before attempting the 8.7.x upgrade):
Drupal version: 8.6.16.
Running
lando drush updbreturns[success] No pending updates.Running
lando drush entupusing devel_entity_updates returnsCompleting the command by typing "yes" returns the following error:
In the database there are tables that look like this:
If I try to upgrade to 8.7 anyways without resolving these entity issues, after the upgrade I get the
'entity:user' context is required and not presenterror in the browser for anonymous users. Runninglando drush updbstill returns[success] No pending updates.butlando drush entupnow only returns:Now I can successfully run those entity updates using devel_entity_updates but the
'entity:user' context is required and not presenterror for anonymous users remains.I have also tried restoring a MySQL backup from mid April and re-running
lando drush updbfor the 8.6.16 database updates, which runs:After that
lando drush entupreturns[success] No entity schema updates required [success] Finished performing updates.But I still get the sameThe 'entity:user' context is required and not present.error in the browser when trying to upgrade to 8.7.x withlando composer update drupal/core webflo/drupal-core-require-dev --with-dependencies.Running
lando drush updbat this point (after the 8.7 upgrade using the backup) performs:This completes successfully, and there are no pending entity updates, but the error remains for anonymous users.
Thank you for the help!
Comment #5
Newb_Druper commentedI am also having the same issue as @jimafisk. I just wanted to mention it.
I am upgrading from 8.6.16 to 8.7.x and all seems fine with no errors, except for anonymous users get an error below
I am also getting strange tables similar to @jimafisk that are created in my database after the update to 8.7.x
`old_73377etaxonomy_term__field_category_columns`
`old_73377etaxonomy_term__field_category_layout`
`old_73377etaxonomy_term__field_taxonomy_color`
`old_73377etaxonomy_term__parent`
`old_73377etaxonomy_term_data`
`old_73377etaxonomy_term_field_data`
`old_ee6aa4menu_link_content`
`old_ee6aa4menu_link_content_data`
I think I have to look deeper at all my rows in my taxonomy tables before the upgrade to 8.7.x to see if there is something out of the ordinary.
Comment #6
tomdewild commentedWe've had the same problem as @jimafisk and @Newb_Druper with one of our sites. After debugging some time we found out that User 0 was missing in the database and this caused the problem.
Created a small update hook to fix the problem:
Hopefully this will also solve your problems.
Comment #7
jimafisk commentedThanks so much @tomdewild!! Your answer in #6 seems to have fixed our issue!
I swapped out the UUID you listed for the one found in config/default/user.role.anonymous.yml.
Comment #8
Newb_Druper commentedThat worked as well for me. Thanks @tomdewild
I also made sure to use my own UUID as mentioned by @jimafisk
Comment #9
catchUpdated the issue summary. Switching this to a major task, we can't actually fix the issue in core, but we can provide a status report message that informs site admins of the problem.
Comment #10
berdir> I swapped out the UUID you listed for the one found in config/default/user.role.anonymous.yml.
one is the UUID for the role, the other for the user, there's no reason to and you shouldn't reuse it like that.
Comment #12
cestmoi commented@Berdir
I also, after updating from 8.6.1 to 8.8.6, had same issue and seem to have fixed it by creating the user 0 row in the DB with :
INSERT INTO users (uid, langcode, uuid) VALUES (0, "en", "");No error now but the user 0 has no uuid. Is it safe to leave it without a uuid ? and if not then how to create one ?
Another weird observation, I checked the DB of the original Drupal 8.6.1 and found it missing the user 0 too but doesn't have the error of this OP !
Thanks
Comment #16
quietone commentedIs anyone still experiencing this problem?
Comment #17
quietone commentedAdd tag,
Comment #19
quietone commentedSorry, folks I somehow missed catch's comment, #9. This is really a task.
Comment #21
quietone commentedComment #23
quietone commentedThe test failure is
suspected cause is #3316274: Stabilize FunctionalJavascript testing AJAX: add ::assertExpectedAjaxRequest().
Since that is unrelated I am setting to needs review.
Comment #24
smustgrave commentedUpdated the title a bit to easily see what's being added
Verified the user requirement with an anonymous user and without (manually deleted). Attached screenshots to issue summary.
Comment #25
kristiaanvandeneyndeLooks good to me.
Found one nitpick and think we should test this as it's a big issue if you run into it and we want to make sure that user_requirements() does its job properly. The test could be as simple as:
Case 1:
Case 2:
Comment #26
quietone commented@kristiaanvandeneynde, thanks for the review. I have updated the MR accordingly.
Unrelated test failure
Comment #27
dpiSmall thing.
I'd prefer ternary for description and severity rather than the giant if/else but not gonna hold up on that. Defer to author.
Comment #28
kristiaanvandeneyndeLGTM.
I don't want to hold up this issue over personal taste between
empty($result)andcount($result) === 0even though I prefer the former. Thanks for adding the test and addressing the minor nitpicks.Test fail indeed seems unrelated, please run that single pipeline again. For some reason that button and the resolve thread button are missing for me from this MR.
Comment #29
kristiaanvandeneyndePushed some code style changes rather than adding nitpicks and requiring others to do so:
I would leave it at RTBC as the test that was added still goes green and these are merely nitpicks. However, now that I wrote code myself, I shouldn't RTBC it myself as prescribed in the governance docs. Please RTBC if you agree with my cleanup.
FWIW, this is ready to go in for me now so will pass on to a committer once set back to RTBC.
Comment #30
poker10 commentedI have reviewed the MR and added some minor comments.
There also seems to be a codestyle issues after changing the requirements array, see: https://git.drupalcode.org/issue/drupal-3057399/-/jobs/383838
Thanks!
Comment #31
kristiaanvandeneyndeGood review, I missed that documentation copy/paste.
Comment #32
smustgrave commentedBelieve all feedback has been added
Also ran test-only feature
Comment #33
catchThe count query doesn't look right to me, we usually use a range query to check for existence, counts are for counting things.
Also the docs page should be updated to not talk about Drupal 6 any more. https://www.drupal.org/node/1029506
Comment #35
akhil babuI have replaced
countQuery()withrange(0, 1)as per the review comment #33. Please reviewComment #36
smustgrave commented1 small nitpicky item.
Comment #37
akhil babuAdded void typehint.
Comment #38
akhil babuComment #39
smustgrave commentedFeedback has been addressed.
Comment #40
quietone commentedI made some changes that require another review.
Comment #41
smustgrave commentedTesting the changes believe the changes are good.
Comment #42
longwaveAdded a question to the MR. Unsure if we have a policy for things that belong in the status report.
Comment #43
smustgrave commentedIf we remove that bit to a follow up could the rest make it?
Comment #44
kristiaanvandeneyndeThat would be acceptable to me. We shouldn't hold up this issue over a policy discussion about what to do when nothing is wrong.
Comment #45
longwaveYeah the rest of it is fine, I just don't want to clutter the status report with useless messages, as I feel there are already enough of them.
Comment #46
quietone commentedI made the change suggested in the MR. Since that changed logic, I made a new screenshot, just to be sure.
Comment #47
poker10 commentedAdded one comment to the MR about comment wording.
Also, the IS states:
However, we use
REQUIREMENT_ERRORinstead ofREQUIREMENT_WARNINGin the code. Do we need to update the IS, or change the code to useREQUIREMENT_WARNING?Thanks!
Comment #48
quietone commentedOops, yes the IS does say warning. I have made that change, made another screenshot and updated the IS.
Comment #49
smustgrave commentedSeems the extra bit discussed in #42-45 has been removed.
Comment #50
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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.
Comment #51
quietone commentedThis just needed
declare(strict_types=1);added to the one test here. I did that and a rebase. There were no conflicts, so I am restoring the RTBC.Comment #52
poker10 commented@catch in #33 mentioned we should also update the documentation page (https://www.drupal.org/node/1029506) and remove mentions about D6. I have updated it - feel free to update it further if needed (especially the D10+ part). Also tested the MR manually and the warning is displayed correctly when anonymous user is missing.
+1 to RTBC from me.
Comment #54
alexpottI left a comment on the MR to address.
Comment #56
pradhumanjain2311 commentedApplied Entity Query As Requested Please Review.
Comment #57
kristiaanvandeneynde@pradhumanjain2311 All you did was apply a suggested change verbatim. In that case you can set it back to RTBC :)
Comment #60
catchCommitted/pushed to 11.x and cherry-picked to 10.3.x, thanks!