When decorating the current_route_match service I'm seeing issues with various webform requests (either fatal errors or ajax responses making no changes) when navigating past page two of a multi-page form and in some other areas. Based on my debugging this may be more of a general form issue than a webform issue as it seems to be caused by the form display missing from the form storage in Drupal\Core\Entity\ContentEntityForm::getEditedFieldNames(). Disabling caching by altering forms mitigates it but does not completely remove it.

It is the act of decorating the service that causes the problem, not any override of functionality. The issue occurs even if the decorated service supplies the exact same class. E.g. the issue will be caused by a module consisting of nothing but an .info.yml file and a services file as follows:

    class: Drupal\Core\Routing\CurrentRouteMatch
    decorates: current_route_match
    decoration_priority: 0
    public: false
      - '@request_stack'

I'm pretty stumped on this. Why would this possibly be happening? Or how could I even go about debugging something like this?

  • 1
    You set public: false why is that? That will make the service* unusable in code, you can only use it as an argument for other services.
    – Beebee
    Dec 4, 2020 at 16:27
  • @Beebee It's copied from another more complicated decorator and service, this is a stripped down version for testing/demonstration. The original decorator applies changes to the current_route_match service to be used when that service is available. Switching public to true does not affect the issue.
    – Dylan
    Dec 4, 2020 at 16:53
  • @Beebee wait, now it does, at least on my test site. I'm positive that didn't fix it before.
    – Dylan
    Dec 4, 2020 at 16:59
  • you need to cache:rebuild in between changes to *.services.yml files else they won't get picked up most likely. I'm pretty sure setting public: false will cause lots of issues since the current route match service is quite heavily used in other modules, not just as a service argument, but in code.
    – Beebee
    Dec 4, 2020 at 17:07
  • 1
    I figured out why this was still broken on the one site. Bit anticlimactic but I had a form alter where caching of the webform was disabled (ironically as a partial workaround for this same issue). That form alter was causing a very similar issue to happen even when the fix that worked for other sites (setting public: true on the decorator) was applied.
    – Dylan
    Dec 7, 2020 at 16:13


Your Answer

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

Browse other questions tagged or ask your own question.