Bug Custom state provider

[mgrr]

I have 3 entities:

• EventCategoryPrivate
• EventPrivate
• EventStatusPrivate

I defined custom provider like this :
#[ApiResource(normalizationContext: ['groups' => ['read']], routePrefix: '/v1/private', operations: [new GetCollection(uriTemplate: '/event/categories', provider: EventCategoryPrivateStateProvider::class)
#[ApiResource(normalizationContext: ['groups' => ['read']], routePrefix: '/v1/private', operations: [new GetCollection(uriTemplate: '/events', provider: EventPrivateStateProvider::class)
#[ApiResource(normalizationContext: ['groups' => ['read']], routePrefix: '/v1/private', operations: [new GetCollection(uriTemplate: '/event/statuses', provider: EventStatusPrivateStateProvider::class)

when i m requesting event statuses, it arrive in the EventPrivateStateProvider. It 's not normal, i should be in the EventStatusStateProvider. it consider like id and not get collection.
when i m requesting event category, it arrive in the EventCategoryStateProvider. It's normal.

I tested to change the name of entity EventStatusPrivate to EventCStatusPrivate to be before EventPrivate in the alphabetic order.
And now it s running when i m requesting i m in the EventStatusPrivateStateProvider.

Can you correct this bug ?

Mathieu

[soyuka]

Not sure I understand the configuration, are all these resources on the same class?

[mgrr]

No it s in 3 differents classes. In fact, api platform parse the classes in alphabetic order and like eventPrivate is before eventStatusPrivate, the configuration of eventStatusPrivate is not saved by api platform.

when i request /event/statuses with get, api platform understand statuses is the id of event. he ignore the configuration of eventStatusPrivate.

To resolve this problem, i changed the url to :
/eventcategories to replace /event/categories
/events to replace /events
/eventstatuses to replace /event/statuses

[soyuka]

This was a route name collision. Two operations resolved to the same Symfony route name, and RouteCollection::add() silently replaced the first one, so the winner depended on class discovery order. That is why renaming the class changed which provider ran.

Fixed by #8502, shipped in 4.4.0 and 5.0.0. ApiLoader now throws and names both declaring classes instead of dropping a route, and a NotExposed operation can no longer displace an exposed one regardless of discovery order.

If you still see a misrouted provider on 4.4.1 or later, please reopen with the exception message and the full attributes of the two resources.