Views referencing missing roles fail views_post_update_revision_metadata_fields()

This patch should help with that error, but the actual problem in your case is that you have view with an (somewhat broken) outdated configuration, meaning that one of its filters is set to use a role that doesn't exist anymore.

Here's a patch that applies to 8.4.x, the one above was for 8.5.x.

I have the same/similar issue. But I updated with Update.php not Drush.

Please see: https://www.drupal.org/node/2916612

@jnimchuk, does the patch from #5 work for you as well?

Sorry, but the patch doesn't work for me. Here's the message from my log:

Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of /var/www/vhosts/thejdngroup.com/domains/test8.portrevolt.com/core/modules/system/src/Controller/DbUpdateController.php) #0 /var/www/vhosts/thejdngroup.com/domains/test8.portrevolt.com/core/includes/bootstrap.inc(566): _drupal_error_handler_real(8, 'Undefined offse...', '/var/www/vhosts...', 413, Array) #1 /var/www/vhosts/thejdngroup.com/domains/test8.portrevolt.com/core/modules/system/src/Controller/DbUpdateController.php(413): _drupal_error_handler(8, 'Undefined offse...', '/var/www/vhosts...', 413, Array) #2 /var/www/vhosts/thejdngroup.com/domains/test8.portrevolt.com/core/modules/system/src/Controller/DbUpdateController.php(179): Drupal\system\Controller\DbUpdateController->results(Object(Symfony\Component\HttpFoundation\Request)) #3 [internal function]: Drupal\system\Controller\DbUpdateController->handle('results', Object(Symfony\Component\HttpFoundation\Request)) #4 /var/www/vhosts/thejdngroup.com/domains/test8.portrevolt.com/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #5 /var/www/vhosts/thejdngroup.com/domains/test8.portrevolt.com/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #6 /var/www/vhosts/thejdngroup.com/domains/test8.portrevolt.com/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #7 {main}.

The patch in #5 didn't have an effect on the error for me either. Looks like I have the same error as #9

Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of /home/www/public_html/core/modules/system/src/Controller/DbUpdateController.php) #0 /home/www/public_html/core/includes/bootstrap.inc(566): _drupal_error_handler_real(8, 'Undefined offse...', '/home/www...', 413, Array) #1 /home/www/public_html/core/modules/system/src/Controller/DbUpdateController.php(413): _drupal_error_handler(8, 'Undefined offse...', '/home/www...', 413, Array) #2 /home/www/public_html/core/modules/system/src/Controller/DbUpdateController.php(179): Drupal\system\Controller\DbUpdateController->results(Object(Symfony\Component\HttpFoundation\Request)) #3 [internal function]: Drupal\system\Controller\DbUpdateController->handle('results', Object(Symfony\Component\HttpFoundation\Request)) #4 /home/www/public_html/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #5 /home/www/public_html/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #6 /home/www/public_html/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #7 {main}.

Any update on this issue?

Hi,

what do I do about a Missing / broken handler?
How d I fix that?

Hi maxilein,

Can you please describe the view on which you are facing such issue. I am not able to replicate this issue on my local, which doing the update.

For me the view is failing to update for:

views_post_update_revision_metadata_fields.module

See my previous post #9.

1 pending update
views module

Fix table names for revision metadata fields.

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /update.php/start?id=233&op=do_nojs&op=do
StatusText: Internal Server Error
ResponseText:

The update process was aborted prematurely while running update # in views_post_update_revision_metadata_fields.module. All errors have been logged. You may need to check the watchdog database table manually.

Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of //../web/content/core/modules/system/src/Controller/DbUpdateController.php)
#0 //../web/content/core/includes/bootstrap.inc(566): _drupal_error_handler_real(8, 'Undefined offse...', '/...', 413, Array)
#1 //../web/content/core/modules/system/src/Controller/DbUpdateController.php(413): _drupal_error_handler(8, 'Undefined offse...', '/...', 413, Array)
#2 //../web/content/core/modules/system/src/Controller/DbUpdateController.php(179): Drupal\system\Controller\DbUpdateController->results(Object(Symfony\Component\HttpFoundation\Request))
#3 [internal function]: Drupal\system\Controller\DbUpdateController->handle('results', Object(Symfony\Component\HttpFoundation\Request))
#4 //../web/content/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array)
#5 //../web/content/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request))
#6 //../web/content/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#7 {main}.

I am having exactly this issue updating database tables after upgrading to 8.4.2. Providing my logs here in case they help. Have attempted the fix in #9 but got no extra info from it.

update.php tells me:

1 pending update
views module
Fix table names for revision metadata fields.

On running the updates, it says it has completed "1 of 2" (having said only 1 pending), then fails:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /update.php/start?id=123&op=do_nojs&op=do
StatusText: OK
ResponseText: 
Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /var/sites/c/cbrd.co.uk/public_html/core/lib/Drupal/Core/TypedData/DataDefinition.php on line 30

The error page says:
The update process was aborted prematurely while running update # in views_post_update_revision_metadata_fields.module. All errors have been logged. You may need to check the watchdog database table manually.

And finally the log entry says:
Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of /filepath/public_html/core/modules/system/src/Controller/DbUpdateController.php) #0 /filepath/public_html/core/includes/bootstrap.inc(566): _drupal_error_handler_real(8, 'Undefined offse...', '/filepath...', 413, Array) #1 /filepath/public_html/core/modules/system/src/Controller/DbUpdateController.php(413): _drupal_error_handler(8, 'Undefined offse...', '/filepath...', 413, Array) #2 /filepath/public_html/core/modules/system/src/Controller/DbUpdateController.php(179): Drupal\system\Controller\DbUpdateController->results(Object(Symfony\Component\HttpFoundation\Request)) #3 [internal function]: Drupal\system\Controller\DbUpdateController->handle('results', Object(Symfony\Component\HttpFoundation\Request)) #4 /filepath/public_html/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #5 /filepath/public_html/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #6 /filepath/public_html/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #7 {main}.

Similar problem for me:

drush updb
The following updates are pending:

views module :
  Fix table names for revision metadata fields.

Do you wish to run all pending updates? (y/n): y
Malformed backend packet                                                                                                            [error]
Post updating views                                                                                                                 [ok]
Failed: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "current_user_profile" plugin does not exist. in   [error]
Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of
/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
The command could not be executed successfully (returned: DRUSH_BACKEND_OUTPUT_START>>><<<DRUSH_BACKEND_OUTPUT_END, code: 1)       [error]
Cache rebuild complete.                                                                                                             [ok]
Finished performing updates.

I tracked down the view where the problem is, group member search: /group/1/member-search which has this error after the 8.4.0 upgrade, but not with 8.3.7:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;current_user_profile&quot; plugin does not exist. in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">52</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;current_user_profile&#039;) (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory-&gt;createInstance(&#039;current_user_profile&#039;, Array) (Line: 84)
Drupal\Component\Plugin\PluginManagerBase-&gt;createInstance(&#039;current_user_profile&#039;) (Line: 1111)
Drupal\views\Plugin\views\argument\ArgumentPluginBase-&gt;getPlugin(&#039;argument_default&#039;) (Line: 787)
Drupal\views\Plugin\views\argument\ArgumentPluginBase-&gt;getDefaultArgument() (Line: 1091)
Drupal\views\ViewExecutable-&gt;_buildArguments() (Line: 1265)
Drupal\views\ViewExecutable-&gt;build() (Line: 390)
Drupal\views\Plugin\views\display\PathPluginBase-&gt;execute() (Line: 168)
Drupal\views\Plugin\views\display\Page-&gt;execute() (Line: 1628)
Drupal\views\ViewExecutable-&gt;executeDisplay(&#039;page_ici_connect&#039;, Array) (Line: 78)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer-&gt;doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer-&gt;render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer-&gt;Drupal\Core\Render\MainContent\{closure}() (Line: 576)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer-&gt;prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer-&gt;renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber-&gt;onViewRenderArray(Object, &#039;kernel.view&#039;, Object) (Line: 108)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher-&gt;dispatch(&#039;kernel.view&#039;, Object) (Line: 158)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

I think the problem exists when a module does not uninstall correctly and leaves somethings in a table ...

Try to remove and add (manually) again the filters in View which give an error.

I used Drupal 6 for five years before upgrading to version 8. Not once was there an update to core that caused a problem for this long.

This issue was introduced in 8.4; previously no problem.

Will somebody please address this so that we don't have this problem that has lasted months?

Thank you,
John

If it's an "HTTP Result Code: 500" error, it's usually a memory issue. Try increasing your PHP memory to 256MB or higher, and run update again. That got it working for me.

Just updated from 8.3.7 to 8.4.4 and I am having the same problem as well.

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /update.php/start?id=5927&op=do_nojs&op=do
StatusText: parsererror
ResponseText: Recoverable fatal error: Argument 1 passed to Drupal\Core\Entity\EntityStorageBase::loadMultiple() must be of the type array, string given, called in /home//public_html/.com/core/modules/taxonomy/src/Plugin/views/filter/TaxonomyIndexTid.php on line 396 and defined in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 219 of /home//public_html/.com/core/lib/Drupal/Core/Entity/EntityStorageBase.php).



The update process was aborted prematurely while running update # in views_post_update_revision_metadata_fields.module. All errors have been logged.

How can I figure out which view is causing the problem?

Based on this thread and google searches this seems to be a serious problem affecting a lot of users.

@tpelena The error you posted on this update looks different than any other posted on this thread. Is anything logged?

I now see you opened another issue.

Per #24 — increasing the PHP memory to 256M worked for me too.

Thanks Kruser!

I have tried the latest patch with no success (https://www.drupal.org/files/issues/2917006-8.4.x.patch) anyone else have an alternative that works?

Bumping this to critical for visiblity. The update itself isn't the problem, but it's combining with corrupted views to produce the fatal error.

A possible option other than hiding the error would be to try to detect the problem with views in the update itself and correct them before updating.

Re-uploading the patch from #3 which still applies just fine to 8.6.x and 8.5.x.

@Pascal- it looks like line endings are an issue. The patch in #31 has windows line endings. Have a look at https://www.drupal.org/documentation/git/configure for how to configure git so that the correct line endings are used.

Discussed briefly with @alexpott.

Let's add an else with a trigger_error() to inform people there's a problem.

I also think we should open a follow-up to potentially remove the roles from the Views when they're missing from the site (or at least to take a firm decision not to do that if we don't want to).

I'm still getting the same issue I described in #18. I'm now running 8.4.5, and have tried the patch but it makes no difference - database updates still fail and I still get the same error.

Added a trigger_error() as requested above :)

That makes sense. Not sure about tests, seems a bit overkill to have a test view/update test for that.

Reminds me of #2925890: Invalid config structures can result in exceptions when saving a config entity, I still have that applied in some projects.

I definitely think we should have test coverage of this behaviour. I'm not sure it needs to be an update test though. I think we need something to assert that the warning is triggered.

If it's null then the issue showed up, it's the load() for null is the problem, or the $role_id doesn't have info to load. however, try this patch, another thing if the $role_id is 0, this would give you an array null error, which in this case the error would keep triggering all the way, for every view, so no need to trigger errors for this one.

let me know if this one work.

There are a lot of style problems with your patch sam. Also, I think we'd want to have the warning though I haven't tried amateescu's patch out. Seems the only complaint was we needed a test.

@neclimdul can you please share what you see wrong in styles?

Sorry that was a bit of a drive by comment. I meant coding standards aka code style. Drupal has pretty strict standards(https://www.drupal.org/docs/develop/standards) and even when fixing it in a patch it is worth being careful because there are generally issues to fix code style already created and it can make review harder because it distracts from the notable changes.

1. +++ b/core/modules/user/src/Plugin/views/filter/Roles.php
   @@ -14,7 +14,8 @@
   -class Roles extends ManyToOne {
   +class Roles extends ManyToOne
   +{
   
   

   Like changing the { placement. Drupal requires them on the same line.

2. +++ b/core/modules/user/src/Plugin/views/filter/Roles.php
   @@ -88,10 +93,12 @@ public function calculateDependencies() {
   +      // Continue in case of empty role ¶
   

   Also your comment has a space after it and needs a period. Its also a good idea to tell _why_ in your comment instead of stating what the code does. The if and continue already clearly show we're continuing when the role is falsy/empty. But what purpose does that serve? This doubles to help someone reviewing the patch and to the poor soul trying to debug it later.

Thank you @neclimdul, here's the new patch with error trigger and cleaned up file with --standard=Drupal,DrupalPractice

Starting from #42

That patch was RTBC and just needed a test.

I am not sure what #46 was correcting for.

+++ b/core/modules/user/src/Plugin/views/filter/Roles.php
@@ -88,8 +88,12 @@ public function calculateDependencies() {
+        @trigger_error("The {$role_id} role does not exist. You should review and fix the configuration of the {$this->view->id()} view.", E_USER_WARNING);

Was the "@" here intentional?

I couldn't find any other case in core where we use @trigger_error with a E_USER_WARNING though we use @trigger_error with E_USER_DEPRECATED

Removing the "@" and adding a test.

#51 looks great. I wanted to RTBC but went looking for signals that would make me not RTBC. Instead, I found #43 by @Berdir, where he RTBC'd the same set of changes, just without test coverage.

That gives me full confidence to RTBC this :)

Running tests locally show they fail. But rather than expecting a core committer to do the same, I'm just uploading #51 with just the test coverage to prove it fails.

+++ b/core/modules/user/tests/src/Kernel/Views/HandlerFilterRolesTest.php
@@ -95,4 +95,33 @@ public function testDependencies() {
+   * @expectedException \PHPUnit\Framework\Error\Warning
+   * @expectedExceptionMessage The test_user_role role does not exist. You should review and fix the configuration of the test_user_name view.

We don't use these annotations anymore. We use ->expectException() and ->expectExceptionMessage()

D'oh, yes. Sorry about that.

@alexpott thanks for taking a look at the issue. Fixing #53.

@Wim Leers thanks for the test only patch

Also

+++ b/core/modules/user/tests/src/Kernel/Views/HandlerFilterRolesTest.php
@@ -95,4 +95,33 @@ public function testDependencies() {
+    try {
+      $view->calculateDependencies();
+    }
+    catch (\Exception $exception) {
+      $this->fail('Exception should not be thrown before the role is deleted.');
+    }

Since we are now using expectException() we no longer need the try catch.

We can just call expectException() after the first call to $view->calculateDependencies(). Therefore if the first call has an exception the test will fail.

+++ b/core/modules/user/tests/src/Kernel/Views/HandlerFilterRolesTest.php
@@ -95,4 +96,28 @@ public function testDependencies() {
+    // Ensure that no exception is thrown before the role is deleted.

Quibbling - but actually no exception is thrown by runtime code. PHPUnit causes warnings to become exceptions. So they can be tested like this. This should be
Ensure no warning is triggered before the role is deleted.

1. #56 good point. fixed
2. Here is also a version of the patch pre 8.8 where we can't use $this->expectException()

🚢

Crediting @kruser, @jnimchuk for testing the issue and providing feedback
Crediting @catch, @alexpott, @neclimdul for reviews
Crediting @romainlepolh for providing that helped track this down
Crediting @chris5156, @Rick Hood for providing a thorough bug reports

Committed and pushed a90dae47a0 to 9.0.x and 962d2db57e to 8.9.x. Thanks!

Asking other committers for a +1 for backport to 8.8.x

Discussed with @catch and we agreed to backport this to 8.8.x

Closed #2829825: views_post_update_serializer_dependencies() can cause update.php to fail as a duplicate, adding credit.