type error on drush updb

Thanks for reporting - this looks like a duplicate of #3541913: Fatal Error with integer query_depth and query_complexity.

Can you run drush updb first? Maybe there is another update function that triggers too early? Can you post a longer backtrace? Would be interesting to see the origin which code triggered this error.

@klausi: I run in similar issue with drupal/graphql:5.0.0-beta1 together with enabled admin_toolbar contrib module during first run of drush updb. After second run problem is fixed, because graphql update hook 50001 was than already applied.

I run into this issue when updating Thunder 7.5.x to recent Thunder 8.3.x. Maybe @dbosen or someone else from Thunder team has also some idea/opinion here.

From first drush updb run:

...
[notice] Update started: admin_toolbar_tools_update_8203
[error]  Cannot assign null to property Drupal\graphql\Entity\Server::$query_depth of type int
[error]  Update failed: admin_toolbar_tools_update_8203
[notice] Update started: content_lock_update_30001
[notice] Update completed: content_lock_update_30001
[notice] Update started: graphql_update_50001
[notice] Update completed: graphql_update_50001
...
[error]  Update aborted by: admin_toolbar_tools_update_8203
[error]  Finished performing updates.
Failed to run drush @bambi updb: exit status 1

From second drush updb run (graphql_update_50001 already applied on first try):

...
[notice] Update started: admin_toolbar_tools_update_8203
[notice] Update completed: admin_toolbar_tools_update_8203
...
[success] Finished performing updates.

With patch from @oknate I'm not running in any issues during first run of drush updb anymore :)

From first drush updb run with patch #2 applied:

...
[notice] Update started: admin_toolbar_tools_update_8203
[notice] Update completed: admin_toolbar_tools_update_8203
[notice] Update started: content_lock_update_30001
[notice] Update completed: content_lock_update_30001
[notice] Update started: graphql_update_50001
[notice] Update completed: graphql_update_50001
...
[success] Finished performing updates.

Thanks, unfortunately we cannot use the patch from oknate because it would remove type hints, but we want to use type hints.

Ideally we can find a solution that the graphql update function is executed first in all pending update functions. Is there a way that Drupal allows ordering of update functions?

I added a special case for admin_toolbar_tools as dependency in the merge request, which is not a great solution, but should work for your trace of update functions. Can you test if that helps?

Claude Code says:

Assessment

The structure is correct:

  $dependencies['admin_toolbar_tools'][8203] = [
    'graphql' => 50001,
  ];

matches Drupal's hook_update_dependencies format: "before admin_toolbar_tools update 8203 runs, graphql update 50001 must have run." The dependency is inert when admin_toolbar_tools isn't installed, so this is safe for sites that never had the combination.

Minor suggestions

1. Comment could explain the why more concretely. "Prevent type errors when the wrong order of update functions is executed" tells you what the hook does but not what goes wrong. Something like:

  // graphql_update_50001 normalizes query_depth/query_complexity on
  // graphql_servers.* from string to int. If admin_toolbar_tools_update_8203
  // loads server entities before that normalization runs, typed-config
  // validation fails with a type error. See #3561746.

2. No issue link in the code. A @see https://www.drupal.org/project/graphql/issues/3561746 (or the PR URL) would save the next person from a git blame expedition.
3. Scope is narrow but likely sufficient. The dep is pinned to admin_toolbar_tools[8203] → graphql[50001]. If other modules load these same server entities during their own updates they'll hit the same bug, but declaring a defensive dependency for every hypothetical collision would be unreasonable — flag them as they appear.
4. No test. Reasonable to skip — exercising cross-module update ordering in a test harness is a lot of scaffolding for a single line of dependency metadata.
5. Forward-only fix. Sites that already ran 8203 before 50001 can't be rescued retroactively, but in practice the type error would have caused 8203 to fail rather than silently corrupt state, so this is the right place to intervene. No data-migration follow-up needed.

Verdict

Small, targeted, structurally correct. I'd merge as-is, but ask for a slightly more descriptive comment + issue link in the docblock before doing so.

Thanks, your comment violates the Drupal AI contribution policy: "These are patterns that create unnecessary work for maintainers and reviewers: Using AI to generate issue summaries, comments, or reviews that lack independently verified technical insights (e.g., using an AI to summarize a thread simply to gain contribution credits)."
https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett...

Instead, please test the merge request and let me know if it fixes the issue for you.

@klausi thank you for the feedback. I will be more cautious in the future.

I'm not able to replicate the problem.

Only change I made is to move the dependencies up so it doesn't disappear in-between different update hooks and can be easily found above all the updates.

Bug also filed against the admin_toolbar module https://www.drupal.org/project/admin_toolbar/issues/3586889