Catch exceptions thrown by config validation to support developers resolving them

Which contrib/custom module?

I'm facing the same issue when I go to /admin/reports/config-inspector

Similar issue for me when going to the /admin/reports/config-inspector page after upgrading to the latest version:

Symfony\Component\Validator\Exception\UnexpectedTypeException: Expected argument of type "array", "null" given in Drupal\Core\Validation\Plugin\Validation\Constraint\ValidKeysConstraintValidator->validate() (line 23 of /var/www/html/web/core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/ValidKeysConstraintValidator.php).

After downgrading back to the previous version that I was using (2.1.0) the error goes away.

I faced the same issue on my local. I am using demo_umami profile and very few contrib modules.

When running drush config:inspect, I got the following error:

In ValidKeysConstraintValidator.php line 23:
                                                                   
  [Symfony\Component\Validator\Exception\UnexpectedTypeException]  
  Expected argument of type "array", "null" given                  
                                                                   

Exception trace:
  at /var/www/html/core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/ValidKeysConstraintValidator.php:23
 Drupal\Core\Validation\Plugin\Validation\Constraint\ValidKeysConstraintValidator->validate() at /var/www/html/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php:202
 Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateConstraints() at /var/www/html/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php:154
 Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode() at /var/www/html/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php:164
 Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode() at /var/www/html/core/lib/Drupal/Core/TypedData/Validation/RecursiveContextualValidator.php:106
 Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validate() at /var/www/html/core/lib/Drupal/Core/TypedData/Validation/RecursiveValidator.php:93
 Drupal\Core\TypedData\Validation\RecursiveValidator->validate() at /var/www/html/core/lib/Drupal/Core/TypedData/TypedData.php:132
 Drupal\Core\TypedData\TypedData->validate() at /var/www/html/modules/contrib/config_inspector/src/ConfigInspectorManager.php:355
 Drupal\config_inspector\ConfigInspectorManager->validateValues() at /var/www/html/modules/contrib/config_inspector/src/Commands/InspectorCommands.php:222
 Drupal\config_inspector\Commands\InspectorCommands->inspect() at n/a:n/a
 call_user_func_array() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:276
 Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:212
 Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:176
 Consolidation\AnnotatedCommand\CommandProcessor->process() at /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:391
 Consolidation\AnnotatedCommand\AnnotatedCommand->execute() at /var/www/html/vendor/symfony/console/Command/Command.php:326
 Symfony\Component\Console\Command\Command->run() at /var/www/html/vendor/symfony/console/Application.php:1096
 Symfony\Component\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/console/Application.php:324
 Symfony\Component\Console\Application->doRun() at /var/www/html/vendor/symfony/console/Application.php:175
 Symfony\Component\Console\Application->run() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:110
 Drush\Runtime\Runtime->doRun() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:40
 Drush\Runtime\Runtime->run() at /var/www/html/vendor/drush/drush/drush.php:139
 require() at /var/www/html/vendor/drush/drush/drush:4
 include() at /var/www/html/vendor/bin/drush:119

The latest line related to config_inspector in the trace is Drupal\Core\TypedData\TypedData->validate() at /var/www/html/modules/contrib/config_inspector/src/ConfigInspectorManager.php:355.

I simply added var_dump($config_name) prior line 355 to check what config was being validated. In my case, it was search_api_solr.solr_cache.cache_document_default_7_0_0. I deleted my search index/server and disabled the search_api_solr module. After that, the drush command was working as expected.

We are probably all reporting the same issue but on a different config. Given the trace, it is very likely to be a core issue.

See https://www.drupal.org/project/config_inspector/issues/3416934#comment-1...

@Wim Leers this issue was marked fixed but the merge request is still open. Could you merge it and tag a new release?

@Wim Leers - to your question for more info:

This happens to me with several (I guess all) text_long fields.

Running Drupal 10.2.6.

drush config-inspect does not crash for me - reports:

$ drush config:inspect --detail field.field.paragraph.text.field_text
➜  🤖 Analyzing…

 Legend for Data:
  ✅❓  → Correct primitive type, detailed validation impossible.
  ✅✅  → Correct primitive type, passed all validation constraints.
 --------------------------------- -------------------------------------------- ------------- ------
  Key                               Status                                       Validatable   Data
 --------------------------------- -------------------------------------------- ------------- ------
  field.field.paragraph.text.fiel   variable type is string but applied schema
  d_text:default_value.format       class is Drupal\Core\Config\Schema\Mapping
 --------------------------------- -------------------------------------------- ------------- ------

Status report shows a list of errors. When navigating to detail (admin/reports/config-inspector/field.field.paragraph.text.field_text/list), I get an error:

Symfony\Component\Validator\Exception\UnexpectedTypeException: Expected argument of type "array", "string" given in Drupal\Core\Validation\Plugin\Validation\Constraint\ValidKeysConstraintValidator->validate() (line 23 of core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/ValidKeysConstraintValidator.php).
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateConstraints('restricted_html', '0000000000000bb60000000000000000', Array) (Line: 154)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode(Object) (Line: 164)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode(Object) (Line: 164)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode(Object, Array, 1) (Line: 106)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validate(Object, NULL, NULL) (Line: 93)
Drupal\Core\TypedData\Validation\RecursiveValidator->validate(Object) (Line: 132)
Drupal\Core\TypedData\TypedData->validate() (Line: 355)
Drupal\config_inspector\ConfigInspectorManager->validateValues('field.field.paragraph.text.field_text') (Line: 362)
Drupal\config_inspector\Controller\ConfigInspectorController->formatList('field.field.paragraph.text.field_text', Object) (Line: 243)
Drupal\config_inspector\Controller\ConfigInspectorController->getList('field.field.paragraph.text.field_text')

...which seems to suggest Drush is better at protecting against this error, than the UI is?

I tried to patch with the PR from #3416934 (as indirectly suggested by comment #11). Didn't help.

yml as saved in the codebase:

langcode: en
status: true
dependencies:
  config:
    - field.storage.paragraph.field_text
    - paragraphs.paragraphs_type.text
  module:
    - allowed_formats
    - text
third_party_settings:
  allowed_formats:
    allowed_formats:
      - restricted_html
id: paragraph.text.field_text
field_name: field_text
entity_type: paragraph
bundle: text
label: Text
description: ''
required: true
translatable: true
default_value:
  format: restricted_html
default_value_callback: ''
settings: {  }
field_type: text_long

Oddly, I see other fields saved with

default_value:
  -
    format: restricted_html

But then when they are re-exported, they show

default_value:
  format: restricted_html

...and both fields 'crash'. So I don't know if that has anything to do with it.

We have allowed_formats module v2.0.0 installed (see third_party_settings). I now see that we should upgrade because Core can do "allowed formats" now. But I don't know if that has anything to do with the error. From what I can see while xdebugging, the exception happens when inspecting "format: restricted_html" (just as Drush suggests), not the allowed_formats.

Crash still happens after uninstalling allowed_formats module.

Looks like resolved elsewhere...

Just for reference: this was never resolved.

The status page still crashes on D10.2.

I don't know what happened with the issue branch in #3416934: Config Inspector crashes on 10.1.x + 10.2.x for `type: mapping` with `nullable: true` due to core bug: whether it was just forgotten, or maybe not applicable for some reason.

Either way: it doesn't matter anymore, since we all moved on to D10.3+ now.

Actually, this still happens on my D10.3 too.

So the status is still what it was per #12 and I'm setting this back to active.

By now, I should probably re-check

• whether I can isolate the configuration that is causing this, and describe it better, and make this into a 'fail test case'
• whether the MR in #3416934 solves this. (Unfortunately, I found this validation code quite hard to make sense of, last time I tried.)

So: reopening, setting to active, and leaving the "Needs steps to reproduce" tag for now. I hope I'll get to it soonish.

Just encountered the same error while testing on 10.4.1 with standard profile on a fresh install.

I then disabled a custom module I was debugging and the page displayed fine again.

Perhaps the exception could be gracefully handled instead of crashing with the error mentioned in the IS ?

Otherwise this issue doesn't seem to be preventing from using the module properly and doesn't seem to come from the module itself, thus lowering the priority to normal.

Thanks in advance!

@dydave: can you get to a reproducible situation? (Does your custom module have imported config and/or a schema in config/schema that you can isolate / share?)

The first thing we'll need to do here, is isolate a situation that causes the crash. And ideally make a failing test case out of it.

I'll re-try based my earlier message... some time. Because I'm still not sure what exactly fails. (I need to re-test what goes wrong with our "restricted_html" config because it has changed since I tested/wrote #12.)

Thanks @roderik!

I was working on the following issue #3499850: Add module configuration schema file and while debugging the config_object I was trying the type 'route' for :
https://git.drupalcode.org/project/login_switch/-/merge_requests/4/diffs...

So in other words, for example:

    register_route:
      type: route
      label: 'Enter a route to replace user/register route'

If you try using the type route for example, the error should appear immediately and the page /admin/reports/config-inspector crash.

Hope this will help reproducing the issue.

Let us know if there is anything else we could do to help.
Thanks in advance!

For me, when config of default value format was:

default_value:
  format: restricted_html

/admin/reports/config-inspector was failing, complaining that format has to be an array, not the string (message from ticket description).

After changing config file to:

default_value:
  format:
    - restricted_html

Error message was gone and page was displayed correctly.

I was inspired by the recent #3359846: Crashes on leftovover themeconfig PR to look at the code again and could make some sense of it (because I now understand/think that I can ignore the impenetrable TypedData code). #3359846 does (almost) the same thing to different code, btw.

Proposed fix included in new MR. And...

• ...do we actually need tests (and steps to reproduce) here?
• Or can we just assume that
  • TypedData stuff can throw any old exception
  • and we just need to deal with it (i.e. catch it and turn it into a violation)?

I think it's the second. I think this just needs a try-catch + return error, and I don't need to bother about writing tests that cause any exception.

Manual testing done

• UI:
  • Before: fatal error
  • After: the row for the offending config item reports "1 error"
  • The actual / a better error is reported in the list/detail screen. (In my case: "variable type is string but applied schema class is Drupal\Core\Config\Schema\Mapping". This does not change / did not suffer from the fatal error.
• drush config:inspect:
  • the fatal error is never reached, because inspector->validateValues() is called before inspector->checkValues(), which is (I think) therefore never called and doesn't get a chance to choke.
  • however, if it was called, this try/catch gives better output. (I tried. Before the fix, you only get the fatal error reported by drush.)

Reproducing the error (though I'm arguing it's unnecessary)

1) we have #19

2) Putting comments #12 and #20 in context:

If you have a formatted text field, and you change the default value to

default_value:
  format: restricted_html

and import that: this will cause the fatal error in the issue title.

Random useless info

This is of course a completely bogus value: the actual default value would be:

default_value:
  -
    value: '<p>this is my default text</p>'
    format: restricted_html

...and Core does not allow an empty "value".

Our config did, however, have only a default format in the config, like:

default_value:
  -
    format: restricted_html

...which, I assume, was somehow necessary to work around a bug / select the correct default format, when allowed formats was still implemented in contrib (allowed_formats module). But:

• Core does not allow to save a default format without a value, through the UI
• a drush config:export will re-export this format-without-value in the first-above faulty format which causes the fatal error when you re-import the exported file.

Anyone tested this other than roderik? Not that I don't trust roderik but a second set of eyes would be great :)

Tested and works well.

i can confirm that the PR fix the issue for me too.

I can also confirm that the PR fix the issue for me too.
(Drupal 11, PHP 8.3)

RTBC++ bumping priority because I can't see the report page.

#3416934: Config Inspector crashes on 10.1.x + 10.2.x for `type: mapping` with `nullable: true` due to core bug was just merged (even though it was marked fixed 2 years ago). That issue was mentioned above as it exposes the same error message. However I think this strengthening of the behaviour of config inspector with invalid schemas is a good idea since it will actually report such issues instead of throwing exceptions. As a developer tool I agree it should report issues instead of break hard.

Thank you Gàbor, I am interested to see this in action, where it helps me spot missing or broken schema.