BC break in 4.2 ApiResource is excluded from container

[VincentLanglet]

API Platform version(s) affected: 4.2.0

Description
In 4.1 I was using ApiResource on some custom controller to provide doc, for instance:

#[ApiResource(
    shortName: 'Authentication',
    operations: [
        new Post(
            uriTemplate: '/auth/refresh',
            controller: self::class.'::refresh',
            openapi: new Operation(
                tags: ['Authentication'],
                summary: 'Refresh an authentication token',
                description: 'Provides a new token pair in exchange for a valid refresh token.',
            ),
            read: false,
            deserialize: false,
            write: false,
            serialize: false
        ),
    ],
)]

It was working perfectly, but since 4.2 this break the application by excluding the controller from the container.
I'm getting

Operation "_api_/auth/refresh_post" is defining an unknown service as controller "Account\Controller\AuthController". Make sure it is properly registered in the dependency injection container in . (which is being imported from "/app/config/routes/api_platform.yaml"). Make sure there is a loader supporting the "api_platform" type.

How to reproduce
Add ApiResource to a controller or any service.

I understand it might be considered as weird to declare a Controller as resource but it was pretty useful to document some custom controller routes. I'm not sure there is another easy way so far ?

Possible Solution
Removing ->addTag('container.excluded', ['source' => 'by #[ApiResource] attribute']);

Additional Context
Bug introduced in #6943 cc @GromNaN

[GromNaN]

Is the method refresh static? If so, the class should not have to be instantiated by the container. Otherwise it's not correct to use a DTO as a service.

[VincentLanglet]

Is the method refresh static? If so, the class should not have to be instantiated by the container.

No it's not static, it's a classic route from a controller AuthController extends AbstractController

Otherwise it's not correct to use a DTO as a service.

I feel like it's the misunderstanding here. I don't plan to use a DTO as a service, I just wanted to define route and document them. Like other ApiResource

With the ApiResource attribute I was able to get the following doc

I had the benefit

• To get an easy definition and documentation of my routes
• To get similar route name than the one for my entities

If it's not correct what is the right way to do such when there is no entity related to those routes ?

Also, even if "not correct", this was working fine on 4.1 so this change is still a BC break :/

[GromNaN]

Thanks for the details. I create a PR to be able to keep the service for a given class. #7403

You can also disable autoconfiguration on the class.

[VincentLanglet]

After multiple tries, I feel like I can get my old behavior with just

#[Post(
            uriTemplate: '/auth/refresh',
            controller: self::class.'::refresh',
            openapi: new Operation(
                tags: ['Authentication'],
                summary: 'Refresh an authentication token',
                description: 'Provides a new token pair in exchange for a valid refresh token.',
            ),
            read: false,
            deserialize: false,
            write: false,
            serialize: false
)]

So maybe it can be considered a good-enough solution @GromNaN ?

• I don't have to declare the Controller as ApiResource (which was indeed wrong)
• But I still enjoy the documentation

[rvanlaak]

Great that attributing any service with an operation still works, as the controller semantically indeed isn't considered to be a resource. This distinction might be worth a documentation PR?