BC break: could not resolve argument $data of "api_platform.action.placeholder::__invoke()"

[ambroisemaupate]

API Platform version(s) affected: 4.2.2

Description

We enabled use_symfony_listeners: true option because we need it for handling API endpoints with Symfony Controllers. Since v4.2.2, our Processors do not denormalize request body anymore and we experience this error:

Could not resolve argument $data of \"api_platform.action.placeholder::__invoke()\", maybe you forgot to register the controller as a service or missed tagging it with the \"controller.service_arguments\"?

#[Post(
    uriTemplate: '/request-reset-password-token',
    openapi: new Operation(
        tags: ['User'],
        summary: 'Request a new password reset token',
        description: 'Request a new password reset token for a user email address. The token will be sent to the user email address.',
    ),
    description: 'Request a new password reset token',
    denormalizationContext: [
        'groups' => ['reset-password:request'],
        'enable_max_depth' => true,
    ],
    validationContext: ['groups' => ['Default', 'requestValidation']],
    name: 'Request Reset Password Token',
    processor: RequestResetPasswordTokenProcessor::class,
)]

How to reproduce

• Enable use_symfony_listeners: true api-platform configuration option
• Create a POST/PATCH operation using a custom ProcessorInterface

Possible Solution

This seems to be related to this PR: https://github.com/api-platform/core/pull/7449/files which removes $request->attributes->set('data', $data); from DeserializeListener, and only add it to DeserializeProvider.

If I disable use_symfony_listeners: false, this fixes the issue. But this is not a acceptable solution and leads to backward compatibility break.

[VincentLanglet]

This seems to be related to this PR: #7449 (files) which removes $request->attributes->set('data', $data); from DeserializeListener, and only add it to DeserializeProvider.

cc @soyuka

Since you're exposing the data with read_data attribute, maybe it's not necessary to remove

$request->attributes->set('data', $data);

from DeserializeListener ?

@ambroisemaupate Would you consider trying a PR re-adding it ? To see if added tests are still green.

[ambroisemaupate]

I'll submit a PR soon @VincentLanglet

[ambroisemaupate]

I've an update: this occured when using:

api-platform/symfony: "4.2.2"
api-platform/state: "!= 4.2.2"

We fixed api-platform/state to version 4.2.1 because 4.2.2 broke our phpstan tests (see #7452). So in our case, src/State/Provider/DeserializeProvider.php was not up to date to provide data request attribute.

That is a side-effect, but this highlights that api-platform/symfony is dependant strictly to api-platform/state. And api-platform/state still uses Symfony to provide Request attributes.

@VincentLanglet @soyuka Is a PR still required? Or maybe a strictier version constraint to forbid using api-platform/symfony: "4.2.2" with a lower api-platform/state version?

[VincentLanglet]

That is a side-effect, but this highlights that api-platform/symfony is dependant strictly to api-platform/state. And api-platform/state still uses Symfony to provide Request attributes.

@VincentLanglet @soyuka Is a PR still required? Or maybe a strictier version constraint to forbid using api-platform/symfony: "4.2.2" with a lower api-platform/state version?

I would say it's too late because it will require api-platform/state 4.2.2 for the api-platform/symfony 4.2.3 version, but the 4.2.2 version will still allow api-platform/state 4.2.1. Unless the previous release is deleted/recreated, which is not an easy task I think.

[VincentLanglet]

We fixed api-platform/state to version 4.2.1 because 4.2.2 broke our phpstan tests (see https://github.com/api-platform/core/pull/7452).

I commented the PR @ambroisemaupate ; please comment the PR with your usage if it's different.