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:
services:
decorator_test.route_match:
class: Drupal\Core\Routing\CurrentRouteMatch
decorates: current_route_match
decoration_priority: 0
public: false
arguments:
- '@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?
public: falsewhy is that? That will make the service* unusable in code, you can only use it as an argument for other services.cache:rebuildin between changes to*.services.ymlfiles else they won't get picked up most likely. I'm pretty sure settingpublic: falsewill 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.