Changes to service definitions can cause fatal errors until services cache is cleared

[jrockowitz]

Hi,

@benjifisher Recently created Issue #3022909: Update functions request non-existent services in the Webform issue queue which lead me to look at Drupal core's Issue #2918906: Changes to service definitions can cause fatal errors until services cache is cleared

I think @daniel.nitsche's comment #7 has some merit so I decided to take my first crack at using GitHub. (Yep, I only familiar with Drupal.org and BitBucket).

The solution/concept is to use the composer.lock file's hash as Drupal's deployment identifier in settings.php. This approach guarantees that when any Drupal core or contrib code is updated via composer, Drupal's service definitions are updated.

I forked the main repos and created this branch with a single commit.

Is this a good idea?

Is calling file_get_contents() too much of a performance hit?

Does this successfully prevent fatal errors when service definitions are changed?

---

A slight different approach which I just thought of would be to use the composer.lock files modified timestamp. This solution requires no changes to 'drupal-composer' and would just need to be documented.

$settings['deployment_identifier'] = filemtime('../composer.lock');

[jrockowitz]

I just read Cost of file modification time checks and using filemtime() is clearly much faster than using file_get_contents(). Still, we are only talking about a few milliseconds.

[weitzman]

I'd be fine with that change. Lets see what others thing. Ping @webflo

[rodrigoaguilera]

I also think the composer.lock last modification time should be part of the deployment identifier

[AlexSkrypnyk]

This pull request/issue has been inactive for over a year and is being closed due to inactivity. If the issue still persists or the contribution is still relevant, please feel free to reopen it or create a new one.

Thank you for your understanding and your contributions to the project!