0

I have upgraded to Drupal 8.4.0 (from 8.3.7) with composer, using webflo/drupal-core-strict to maintain the proper core dependencies.

When I run drush updb (with drush 8.1.15) to update the database, I get the following error:

Symfony\Component\DependencyInjection\Exception\RuntimeException: Constructing service "validation.constraint" from a parent definition is not supported at build time. in /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php on line 847 #0 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(451): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\DefinitionDecorator), 'validation.cons...')
#1 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(957): Symfony\Component\DependencyInjection\ContainerBuilder->get('validation.cons...', 1)
#2 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(954): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Object(Symfony\Component\DependencyInjection\Reference))
#3 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(1145): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Array)
#4 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(918): Symfony\Component\DependencyInjection\ContainerBuilder->callMethod(Object(Drupal\Core\Config\TypedConfigManager), Array)
#5 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(451): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), 'config.typed')
#6 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(957): Symfony\Component\DependencyInjection\ContainerBuilder->get('config.typed', 1)
#7 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(954): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Object(Symfony\Component\DependencyInjection\Reference))
#8 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(879): Symfony\Component\DependencyInjection\ContainerBuilder->resolveServices(Array)
#9 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(451): Symfony\Component\DependencyInjection\ContainerBuilder->createService(Object(Symfony\Component\DependencyInjection\Definition), 'config.factory')
#10 /var/www/docroot/modules/contrib/libraries/src/LibrariesServiceProvider.php(29): Symfony\Component\DependencyInjection\ContainerBuilder->get('config.factory')
#11 /var/www/docroot/core/lib/Drupal/Core/DependencyInjection/Compiler/ModifyServiceDefinitionsPass.php(30): Drupal\libraries\LibrariesServiceProvider->alter(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#12 /var/www/vendor/symfony/dependency-injection/Compiler/Compiler.php(120): Drupal\Core\DependencyInjection\Compiler\ModifyServiceDefinitionsPass->process(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#13 /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php(573): Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#14 /var/www/docroot/core/lib/Drupal/Core/DrupalKernel.php(1307): Symfony\Component\DependencyInjection\ContainerBuilder->compile()
#15 /var/www/docroot/core/lib/Drupal/Core/DrupalKernel.php(884): Drupal\Core\DrupalKernel->compileContainer()
#16 /var/www/vendor/drush/drush/lib/Drush/Drupal/DrupalKernel.php(61): Drupal\Core\DrupalKernel->initializeContainer()
#17 /var/www/docroot/core/lib/Drupal/Core/DrupalKernel.php(466): Drush\Drupal\DrupalKernel->initializeContainer()
#18 /var/www/vendor/drush/drush/lib/Drush/Boot/DrupalBoot8.php(146): Drupal\Core\DrupalKernel->boot()
#19 /var/www/vendor/drush/drush/includes/bootstrap.inc(354): Drush\Boot\DrupalBoot8->bootstrap_drupal_full()
#20 /var/www/vendor/drush/drush/includes/bootstrap.inc(473): drush_bootstrap(5, 6)
#21 /var/www/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(59): drush_bootstrap_to_phase(6)
#22 /var/www/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#23 /var/www/vendor/drush/drush/drush.php(12): drush_main()
#24 {main}
Drush command terminated abnormally due to an unrecoverable error.   [error]
Symfony\Component\DependencyInjection\Exception\RuntimeException: Constructing service "validation.constraint" from a parent definition is not supported at build time. in Symfony\Component\DependencyInjection\ContainerBuilder->createService() (line 847 of /var/www/vendor/symfony/dependency-injection/ContainerBuilder.php).

Could anyone point me in the right direction to track down this error?

1
  • Are you using Libraries API module per chance? – Kevin Oct 12 '17 at 18:35
2

About Drush 8 the release notes of Drupal 8.4.0 are a bit misleading. Drupal 8.4 + Drush 8 (8.1.12 or higher) work only globally, but you are using Drush locally (in the vendor directory), so you need Drush 9:

composer require drush/drush:~9.0

BTW using Drush 9 is the recommend way. Despite that it is not stable yet, it's nonetheless the more stable solution, because it uses the same Symfony version as D8.4, while Drush 8 still has the old Symfony version of D8.3 to maintain backward compatibility.

3
  • Thanks for the suggestion! Much appreciated! Even after upgrading to 9.0.0-beta-7 I still get the same error: [error] Constructing service "validation.constraint" from a parent definition is not supported at build time. [0.21 sec, 14.52 MB] Any other suggestions? I guess one explanation would be an unexpected interaction with a contrib module, though I couldn't find any clues in the output. The last time I had trouble upgrading it was because I got different versions of some packages, but I haven't had any trouble with that since I started using drupal-core-strict – Em D Oct 10 '17 at 13:43
  • 1
    Are you using the local binary of drush (use drush status to check this)? – 4k4 Oct 10 '17 at 13:50
  • Drush status gives the same error message (validation.constraint), drush version gives 9.0.0-beta-7 after I changed it in composer.json and ran composer update. I can verify that the same version of drush 9 is used within the docroot of that site as the newest one available via composer, and that drush 8.1.10 is used outside of the site folder structure. This is within a docksal local dev environment using fin drush as well as with fin bash to get into the docksal container shell and then drush, and then also verified on the staging server. – Em D Oct 11 '17 at 9:10
1

I am experiencing the same problem, and opened an issue on drupal.org here: https://www.drupal.org/node/2915332

As my comment (#4) on drupal.org suggests, I think this is a Drupal (or contrib) bug that has nothing to do with Drush. I believe it will need to be fixed by the Drupal developers, but you can test my workaround below (please note the WARNING):

Environment

my site is running on Pantheon with PHP 7.0.

Background

I initiated the site update via Pantheon's interface, which I believe is running Drush on the back end to handle this operation. Once I ran into this issue after trying to update, any/all drush commands (including cache clearing) result in the same error. The problem is that the application is unable to bootstrap itself and spin up, thus it cannot fulfill any requests (web, Drush, or otherwise). As far as I can tell, the system is failing to spin up because it is choking on the core Drupal configuration in core/core.services.yml that I referenced at the end of my issue.

When the Kernel is booting, it is instantiating the config.typed configuration, which in turn calls the validation.constraint which is configured with a parent attribute, making it a configuration instance of DefinitionDecorator instead of Definition. Consequently, the createService() method on ContainerBuilder is choking right off the bat with:

if ($definition instanceof DefinitionDecorator) {
    throw new RuntimeException(sprintf('Constructing service "%s" from a parent definition is not supported at build time.', $id));
}

As the message suggests: Constructing a service from a parent definition is not supported at build time.

The problem was introduced in this commit when @validation.constraint became a dependency of config.typed via the calls attribute added in the commit:

config.typed:
    class: Drupal\Core\Config\TypedConfigManager
    arguments: ['@config.storage', '@config.storage.schema', '@cache.discovery', '@module_handler', '@class_resolver']
    tags:
      - { name: plugin_manager_cache_clear }
    calls:
      - [setValidationConstraintManager, ['@validation.constraint']]

Workaround TEST

Edit core/core.services.yml and comment out the calls attribute for the config.typed block as follows:

config.typed:
    class: Drupal\Core\Config\TypedConfigManager
    arguments: ['@config.storage', '@config.storage.schema', '@cache.discovery', '@module_handler', '@class_resolver']
    tags:
      - { name: plugin_manager_cache_clear }
    #calls:
    #  - [setValidationConstraintManager, ['@validation.constraint']]

Now go to [your_url]/update.php in a browser. There will be pending database updates that need to run. That's it.

WARNING

I have no idea what the repercussions of the configuration change above are. I don't suggest anyone do this in production. It's just a demonstration of what is causing the problem and how to hack around it. As far as I can tell, this is a Drupal bug stemming from an improper usage of the new Symfony configuration standard. I have no idea why/how this wasn't caught in QA before 8.4.0 was released, but I am guessing it is because only a certain set of circumstances cause the bootstrap process to instantiate config.typed, otherwise everyone who updated to 8.4.0 would be experiencing this problem, and no QA would have passed because all 8.4.0 instances would be choking in this way. I will look into what circumstances in my environment trigger config.typed and report back if I find anything.

EDIT: More Info Below

My testing indicated that my boot strapping process is instantiating configured serviced in this order:

  1. config.factory
  2. config.typed
  3. validation.constraint

Some further inspection of the stack trace suggests that config.factory is being instantiated in code/modules/libraries/src/LibrariesServiceProvider.php. That's coming from the Libraries module, and it looks like @Em D is experiencing the same call (from OP's stack trace):

#10 /var/www/docroot/modules/contrib/libraries/src/LibrariesServiceProvider.php(29): Symfony\Component\DependencyInjection\ContainerBuilder->get('config.factory')

There is a working but not "official" Drupal 8 release. I have it installed because I am using Juicebox module, which requires it.

I've tested putting the original core/core.services.yml file back in place, disabling Juicebox, disabling Libraries, then executing a drush cache clear, and the problem no longer occurs. So, this update problem doesn't affect all systems but does affect those with Libraries module installed.

The question now is, is this really the fault of Libraries module, or is there still an inherent problem with the new config.typed configurations use of validation.constraint in its new calls attribute?

How to Reproduce This Error

If you are on a version below 3.4.0:

  1. install Libraries module
  2. initiate update to 3.4.0 using Drush or whatever method you choose

If you are already on version 3.4.0:

  1. install Libraries module

Workaround/Solution:

Disable Libraries module. This is only a "solution" if you aren't actually dependent on that module. If you downloaded it at some point just to test it, never used it, and forgot to delete it, then disabling it should resolve your problem. If, however, you, like me, are dependent on the Libraries module (or one of your other dependencies is), then uninstalling Libraries and/or the dependent parent module may delete views and other configurations/records/data. You should be sent to a warning page after clicking "Uninstall" if this is the case.

UPDATE

As it turns out, this might only be a problem with Libraries release 8.x-3.x-dev (2016-Nov-13), not the current 8.x-3.x-dev release. Digging more into it now. OP, you could try updating Libraries to the latest 8.x-3.x-dev release before running the 8.4.0 update.

FINAL UPDATE

My Solution:

  1. restore backup
  2. update Libraries Module from 8.x-3.x-dev (2016-Nov-13) to latest 8.x-3.x-dev
  3. Get Pantheon support to restart my webstie container to get around Fatal Error cause by step above (more)
  4. run update.php for good measure
  5. update core to 8.4.0
5
  • Great find, but you could simply say, that Libraries is not working with Drupal 8.4 (BTW the last commit was over half a year ago). – 4k4 Oct 12 '17 at 6:42
  • Thanks @4k4. I realize that would be shorter, but I'm also not certain at this time if this is actually the fault of Libraries module or core. Waiting for feedback from core devs regarding the commit linked above. – 94638857 Oct 12 '17 at 15:21
  • This is probably not related to Libraries: I get the same error trying on Drupal 8.5-dev (fresh install) without Libraries in custom code when trying to get the config.factory service in a compilation pass. – FGM Oct 13 '17 at 15:38
  • Digging into it a bit, it really happens when the container tries to create the config.typed service, so this is really the one with the problem. – FGM Oct 13 '17 at 15:50
  • yes @FMG, config.typed is documented in my answer above (sorry, its a long answer) :) – 94638857 Oct 13 '17 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.