Entity queries must explicitly set whether the query should be access checked or not.

The issues is not about Rate module. We encounter the same error in other modules.
Follow the core issue: https://www.drupal.org/project/drupal/issues/3318457

I did tried with the fix shared by kars4, but it didn't worked for me.

Checkout https://www.drupal.org/node/3201242, this error is module related and some accessCheck function have to be added to entity queries for Drupal 10 support.

I've made a merge request with some changes https://git.drupalcode.org/project/rate/-/merge_requests/11

Here is the patch you can use meanwhile: https://git.drupalcode.org/project/rate/-/merge_requests/11.patch

I might be new to this debugging game, so I'm not sure how much help this will be, but I just added " $query->accessCheck(TRUE); " under every instance of " $query = " in file RateWidgetBase.php and it solved it for me... for now. (There were two instances) In addition to the edit made to RateWidgetField.php

RateWidgetField.php

LINE 197:
$query = \Drupal::entityQuery('rate_widget');
$query->accessCheck(TRUE);

RateWidgetBase.php

LINE 295:
$query = $this->entityTypeManager->getStorage('vote')->getQuery();
$query->accessCheck(TRUE);

LINE 406:
$query = $this->entityTypeManager->getStorage('vote')->getQuery();
$query->accessCheck(TRUE);

I can now view content containing the rate module (any role). Hope this helps for someone (and hopefully someone can elaborate more elegantly and not just this strongarm "fix").

in addition to the amendments needed in #15 I also needed to add the access check to line 461

$query = $this->entityTypeManager->getStorage('vote')->getAggregateQuery('vote');
$query->accessCheck(TRUE);

The merge request from @sebastian-hagens fixed the issues for us.

However the merge request did not apply for 3.x or 3.0.1, so we applied the fork via composer.

Add the following to your composer.json "repositories":

        {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/rate-3331890.git"
        },

And run:

composer require drupal/rate:dev-3331890--entity-queries

In my opinion this is RTBC.

Hiding patches that do not apply.

Works for us.

Patch works.

Uploaded a patch of the current MR that applies to 3.0.1.

It is not necessary to add a patch file when issues have been resolved via Merge Request, you can follow this guide https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-drupal/downloading-a-patch-file, then add the patch from local file in the composer.json file.

I'm aware the patch isn't necessary for maintainers to work with, but I do think it's useful to have until a MR is merged in and tagged.

The static patches are necessary so that other site maintainers can easily reuse them without having to rebase/reupload elsewhere - especially ones targetting a specific version rather than the latest dev as in this case.

I'm unable to use the local file approach because my patches are used in a distribution package, so will require the patches to be available from a remote URL, so uploading it in the issue kills two birds with one stone.

The referenced guide also mentions:

Therefore, it's strongly recommended to lock the patch file versions on production sites. To do so you must download the patch file and use it in composer from a local directory, or upload it to the same issue as a file. If you use the URL to the Gitlab MR directly, your codebase will change without warning, as people work on the merge request.

I agree with Codebymikey. Patch links are easy to use. We don't get lost between codes and repositories at project pages on drupalcode.org

Thank you @codebymikey for the patch.

Is this module maintained? Sorry to see that there is no follow-up on this issue or am I incorrect?

I can confirm patch in #22 solves the problem. Thank you for it :) @Maintainers please make a new release to address it.

I lift up this issue to critical, because it's crashing site rendering with a Fatal PHP error when rate widgets are used on a page.

Updating patch to apply to dev branch

I believe you`ll need this one also. Needed this for my project

For those of you uploading patches of the MR for use in composer patches etc, why not just use the autogenerated patch from the diff?
Eg. https://git.drupalcode.org/project/rate/-/merge_requests/11.diff or https://git.drupalcode.org/project/rate/-/merge_requests/11.patch (in this case Patch doesn't like to apply as it has multiple commits but diff works correctly)

(Just add .patch or .diff to the end of the MR URL)

For what its worth, the MR applies and resolves the issue.

The diff or patch of the merge request both don't apply to version 3.0.1 in my project.

Applying both patches #30 and #31 worked though and solved my WSOD.

@Guido_S see the target version for this issue. I would recommend switching to 3.0.x-dev and retesting.

I'm aware of this, but I can't use dev versions on a production system, so I'm happy the two patches apply to the current released version.
But it would be great if it just could be merged and released so that there is no need for patches.
Especially as the module is marked as d10 compatible when it leads to a WSOD on Drupal 10.1

Indeed! But getting it RTBCed is the fastest way to getting it into release :)
Just wanted to clarify so that it didn’t cause pushback on the otherwise working MR

Applying #30 + #31 to 3.0.1 solved the WSOD here when viewing a node that displays a rate widget.
+1 for RTBC.

I can also confirm that patches #30 and #31 solve this issue. Please merge this and tag a new release. This is a beaking bug in a module that claims to be compatible with Drupal 10, but does not actually work with Drupal 10.1. And depending on where on your page the rate module is used, this might actually be hard to spot.

The patch in #31 does not apply and is actually not needed.
Adding the $query->accessCheck(TRUE); in RateWidgetBase.php at line 442 is sufficient before the query is executed.
Thank you for the patches!
Committing to 3.0.x-dev.