drush updb fails when upgrading to 1.11.0 on Drupal 11.3 because entityqueue_post_update_relationship_limit_queue_list (introduced in #2746067) triggers a schema validation error via ConfigEntityUpdater.

Steps to reproduce:

  1. Have a Drupal 11.3.x site with entityqueue installed.
  2. Have at least one View with an entityqueue relationship filter that has a limit_queue value set.
  3. Update entityqueue from 1.10.x to 1.11.0.
  4. Run drush updb.

Expected result: Database updates run successfully.

Actual result:

[error] entityqueue_post_update_relationship_limit_queue_list threw an exception:
Drupal\Core\Config\Schema\SchemaIncompleteVaultException:
The configuration property
display.default.display_options.filters.entity_queue_in_queue.options.limit_queue
has an invalid value (invalid type).

Root cause: The post-update hook uses ConfigEntityUpdater, which internally calls $view->save(). On Drupal 11.3, ConfigSchemaChecker fires on every entity save. The hook writes an associative array (e.g. ['api_docs' => 'api_docs']) to the limit_queue config property, but the schema defined in entityqueue.schema.yml declares it as type: sequence, which expects a numerically-indexed array. This mismatch causes the exception.

Sites whose Views had no limit_queue value configured are unaffected. The failure only occurs on sites with at least one View using the entityqueue relationship filter with a queue selected.

Possible fixes:

  • Change the schema from type: sequence to type: mapping (or type: ignore) to match the associative array structure the post-update hook writes.
  • Replace ConfigEntityUpdater / $view->save() with direct config factory writes using $config->save(TRUE) (the trusted-data flag that bypasses ConfigSchemaChecker).

Workaround: Pin to 1.10.x by adding a Composer conflict for 1.11.*:

"conflict": {
    "drupal/entityqueue": "1.11.*"
}

Environment: Drupal 11.3.x, entityqueue 1.11.0, drush 13.x.

Issue fork entityqueue-3610768

Command icon 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:

About issue forks

Comments

bdanin created an issue. See original summary.

amateescu made their first commit to this issue’s fork.

amateescu opened merge request !60

amateescu’s picture

amateescu commented
Status: Active » Needs review

Nice find! Can you try the MR and let me know if it fixes the upgrade path?

amateescu’s picture

amateescu commented
Title: drush updb fails upgrading to 1.11.0 — entityqueue_post_update_relationship_limit_queue_list causes schema validation error on Drupal 11.3 » Upgrade path issues when updating to 1.11.0
Version: 8.x-1.11 » 8.x-1.x-dev

I found and reproduced the exact issue you bumped into, and it was caused by very old views that haven't been touched in years, and contained stale configuration.

Also found a similar problem in the smartqueue module, so I fixed that one as well.

  • amateescu committed 2d31d618 on 8.x-1.x 
    fix: #3610768 Upgrade path issues when updating to 1.11.0

By: amateescu...
amateescu’s picture

amateescu commented
Status: Needs review » Fixed

Merged into 8.x-1.x.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

bdanin’s picture

bdanin commented
Status: Fixed » Needs review

Maybe merging auto-closes the ticket? I will review. It seems like at this point the easiest way to review is by installing the dev version of this module.

amateescu’s picture

amateescu commented

Yes, that's the easiest way to test it now :)

bdanin’s picture

bdanin commented
Status: Needs review » Needs work

The fix in commit 2d31d618 does not resolve the issue. The post-update hook entityqueue_post_update_relationship_limit_queue_list still fails because it uses ConfigEntityUpdater, which internally calls $view->save() with full schema validation enabled.

Two failure modes observed:

1. When limit_queue is a scalar string or null, the hook normalizes the value to a list and then calls $view->save(), which immediately throws:

The configuration property display.*.display_options.relationships.entityqueue_relationship.limit_queue.0 doesn't exist.

2. After manually pre-fixing the limit_queue value via \Drupal::configFactory()->getEditable(...)->save(TRUE), the ConfigEntityUpdater continues iterating and hits a separate view with:

The entity does not have an ID.

The root problem is that ConfigEntityUpdater is the wrong tool here — it triggers schema validation on save, which is exactly the thing that breaks during this upgrade path. As discussed earlier in this issue, the correct approach is to write directly to the config factory with the trusted-data flag (->save(TRUE)) to bypass schema validation during the update, similar to how other upgrade hooks handle schema migrations.

amateescu’s picture

amateescu commented

@bdanin, I wouldn't rely on the trusted data concept because it's being deprecated in core, see https://www.drupal.org/node/3348180, so the only reliable solution is to ensure that the changes to the view made in the update function result in a fully functional and valid view.

Can you please attach the yml config of the problematic view, so I can see exactly what's going wrong?

bdanin’s picture

bdanin commented

Thanks for the note on trusted data.

Update on our situation: the default database — which had limit_queue: blog_top_articles as a plain scalar string — actually completes the update without error. So the hook does handle that case correctly.

The failure we are still hitting is on a separate database in our multisite setup, where a views.view.* config entry exists in the database with a missing id field (corrupted config). Because ConfigEntityUpdater calls loadMultiple() on all views, it crashes immediately with:

The entity does not have an ID.

This happens before any limit_queue normalization is attempted. The fix needed is for the hook to handle (or skip) view configs that cannot be loaded as valid entities, so that one corrupted view does not abort the entire update.

amateescu’s picture

amateescu commented
Status: Needs work » Fixed

That's good news, at least for this issue.

On the view with a missing ID, I don't think we can (or even should, if possible) do something about it in the entityqueue update hook, because we can't influence the entity loading process from ConfigEntityUpdater. But it should be a straightforward fix on that site though: just set an ID for that view in config, and run config import before running database updates (as drush deploy does by default).

Setting the status back to fixed since there's no additional work to do on the Entityqueue side. I'll release a new version soon with this fix included.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

bdanin’s picture

bdanin commented

Makes sense, I agree and thank you :)

amateescu’s picture

amateescu commented

The new release is out: https://www.drupal.org/project/entityqueue/releases/8.x-1.12

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.