Expected argument of type "array", "string" given

Created on 2 May 2024, 9 months ago

After installing the module, and then going to the report, it generates this:

Symfony\Component\Validator\Exception\UnexpectedTypeException: Expected argument of type "array", "string" given in Drupal\Core\Validation\Plugin\Validation\Constraint\ValidKeysConstraintValidator->validate()

Drupal Version 10.2.5
Apache 2.4.58
PHP 8.3.6
MariaDB 10.11.7
Memory limit 512M

The errors in the config show in my status page.

๐Ÿ› Bug report
Status

Active

Version

2.1

Component

Code

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States duckydan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @duckydan
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States duckydan

    I guess this would be helpful.

    /web/modules/contrib/config_inspector/src/ConfigInspectorManager.php(355): Drupal\Core\TypedData\TypedData->validate()
    
    /web/modules/contrib/config_inspector/src/Controller/ConfigInspectorController.php(176): Drupal\config_inspector\ConfigInspectorManager->validateValues()
  • Assigned to aman1248
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia aman1248
  • Issue was unassigned.
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia aman1248
  • Status changed to Postponed: needs info 9 months ago
  • ๐Ÿ‡ง๐Ÿ‡ชBelgium wim leers Ghent ๐Ÿ‡ง๐Ÿ‡ช๐Ÿ‡ช๐Ÿ‡บ

    Which contrib/custom module?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States duckydan

    @wim-leers I am not sure how to answer that. I went to the report page for the first time. I didn't pick any module.

  • ๐Ÿ‡จ๐Ÿ‡ทCosta Rica hjuarez20

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

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States RobbyMo

    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.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States duckydan
  • ๐Ÿ‡ซ๐Ÿ‡ทFrance vbouchet

    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.

  • ๐Ÿ‡ณ๐Ÿ‡ฑNetherlands idebr

    See https://www.drupal.org/project/config_inspector/issues/3416934#comment-1... ๐Ÿ› Config inspector stopped working after Drupal 10.2 update Active

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

  • ๐Ÿ‡ณ๐Ÿ‡ฑNetherlands roderik Amsterdam,NL / Budapest,HU

    @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.

  • Status changed to Active 8 months ago
  • ๐Ÿ‡ณ๐Ÿ‡ฑNetherlands roderik Amsterdam,NL / Budapest,HU
  • Status changed to Closed: outdated 5 months ago
  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia dpi Perth, Australia

    Looks like resolved elsewhere...

  • ๐Ÿ‡ณ๐Ÿ‡ฑNetherlands roderik Amsterdam,NL / Budapest,HU

    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 ๐Ÿ› Config inspector stopped working after Drupal 10.2 update Active : 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.

  • ๐Ÿ‡ณ๐Ÿ‡ฑNetherlands roderik Amsterdam,NL / Budapest,HU

    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.

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance dydave

    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!

  • ๐Ÿ‡ณ๐Ÿ‡ฑNetherlands roderik Amsterdam,NL / Budapest,HU

    @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.)

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance dydave

    Thanks @roderik!

    I was working on the following issue ๐Ÿ“Œ Add module configuration schema file Active 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!

Production build 0.71.5 2024