Problem/Motivation
This has been split off from #2738051: \Drupal\views\Plugin\views\query\Sql::getCacheTags and getCacheMaxAge don't take into account that some entities can be NULL, which results in the same error, but the situation and proposed fix is different.
Entities that failed to load result in this error:
Error: Call to a member function getCacheTags() on null in Drupal\views\Plugin\views\query\Sql->getCacheTags() (line 1552 of core/modules/views/src/Plugin/views/query/Sql.php).
I did load testing for a site we are working on and we've actually seen two cases in our project how this can happen:
a) Persistent inconsistent data. In our case, this happened because an already deleted entity was re-saved again (#3029355: Deleting a node deletes the linked group_content entities which then resaves the node), then the query built by views does find the node but an entity load on it fails. I'll open a separate issue to prevent this specific case from happening, but there might be other issues that could lead to this.
b) A race condition. In my case, I was doing a load test where 20 users each created, updated and then deleted a new and finally went to the content overview page. I did that 5x in a loop and had two errors like this on the content overview page. So what I think happened is that the node was deleted *between* executing the view and loading the nodes.
Proposed resolution
At least for the second case, I think we should just drop records where we can't load the main entity completely. Even if we avoid errors on the Sql class, various field plugins for example fail with a similar error, e.g. BulkForm and EntityOperations. That could mean we are hiding problems in a), but we could combine it with a warning log message, if something happens once then it was just a race condition, if it happens on every request then you have to fix the data.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | 3029434-nr-bot.txt | 90 bytes | needs-review-queue-bot |
| #24 | Screenshot 2024-04-24 at 9.46.25 PM.png | 292.59 KB | arunkumark |
| #23 | 3029434-nr-bot.txt | 90 bytes | needs-review-queue-bot |
| #16 | 3029434-16.patch | 15.34 KB | _utsavsharma |
| #16 | interdiff_14-16.txt | 1.11 KB | _utsavsharma |
Issue fork drupal-3029434
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:
Comments
Comment #2
berdirCopied the patch from the other issue and also extended with a check and test coverage for relationships, as that currently reinitializes the results key as a stdClass and then that fails later...
Comment #3
dawehnerI do like the fact that you test this!
Comment #5
berdirTestbot broken?
Comment #6
catchI think we should include the entity type in the error message, then you can go straight from log message without needing to know the view configuration.
Comment #7
rosk0Crosslinking, as those errors was just a symptom of the underlying data caused by linked issues.
Comment #14
berdir@catch: That would be useful but would also make this a bit more complicated. We actually don't know the entity type in this method, we just get a list of entities and it's called twice from \Drupal\views\Plugin\views\query\Sql::loadEntities in separate blocks, so we'd need to add logging there in both cases if loading fails and then skip it without logging in this method. Worth it?
Comment #15
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".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #16
_utsavsharma commentedTried to fix CCF for #14.
Comment #19
berdirCreated a MR for 11.x
Comment #20
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue.
While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)
Comment #22
arunkumarkUpdated the MR with references to the fix done on #2932518: Deprecate watchdog_exception
Comment #23
needs-review-queue-bot commentedThe 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.
Comment #24
arunkumarkVerified, able to merge to 11.x verified in local.
Comment #25
arunkumarkTo confirm bot execution keeping in NR.
Comment #26
needs-review-queue-bot commentedThe 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.
Comment #29
arunkumarkComment #30
smustgrave commentedLeft comment on MR but also has test failures.