BC break: api-platform/state 4.2.3 doesn't work with symfony/object-mapper 7.3

[andreasferber]

API Platform version(s) affected: 4.2.3

Description

PR #7486 added ObjectMapperAwareInterface to ApiPlatform\State\ObjectMapper. However this interface doesn't exist yet in symfony/object-mapper version 7.3.*, it's only about to be introduced in the (as of now unreleased) version 7.4/8.0.

Note that the use of ObjectMapperAwareInterface in the instanceof check in the constructor that already existed before the PR is fine because PHP doesn't consider it an error to check for an interface that isn't defined. However adding the interface to the implements list does require the interface to actually exist.

Possible Solution
api-platform/state should probably provide its own version of ObjectMapperAwareInterface conditionally inheriting from object-mapper's interface only if it's available. ObjectMapper should then implement this interface.

And withObjectMapper shouldn't throw an exception if the decorated object mapper doesn't implement ObjectMapperAwareInterface, instead it should just silently skip the call to $this->decorated->withObjectMapper(). I don't think there's any harm in doing that even with object-mapper 7.4, as in this case the downstream ObjectMapper clearly doesn't expect to be passed down the outer decorator in the first place (eg. because it may not have any need to call into ObjectMapper recursively).

[soyuka]

Hi, just a note that I'm working on this, I should've left the ObjectMapper experimental as several issues came out:

• the object mapper did not work properly on proxies [ObjectMapper] Allow to skip mapping non-initialized source values symfony/symfony#60786 (fixed)
• in the meantime we had an issue with PUT : fix(state): object-mapper reuse related entity #7300 which got fixed but needed the ObjectMapperAwareInterface.
• then there was another issue that the mapper loads every relation lazily [ObjectMapper] Multiple: context array, mapping depth, selective instantiation of lazy objects. symfony/symfony#61357
• this lead to our fix where now ObjectMapper loads embedded objects with a lazy ghost ([ObjectMapper] lazy loading symfony/symfony#62214) (and failed attempts at [ObjectMapper] call ObjectMapperAware callables symfony/symfony#62254 and [ObjectMapper] skip proxy initialization at given depth symfony/symfony#62163).

And we had to review our initial patch at #7521 which makes our decoration totaly obsolete (we don't need the ObjectMapperAwareInterface anymore).

But, this also means that the ObjectMapper of symfony 7.3 is quite unusable with API Platform or leads to several issues and performance problems...

Here I'm hitting a wall, the 7.4 version will be out soon and I strongly recommend to use the 7.4 version. I'll fix this by removing the interface from our decorator anyways. I wish we had 3 minor versions to test out the ObjectMapper but as it'll reach LTS we got quite pressured to integrate the component and provide fixes although to me the component is still trying to get mature... Sorry about this though, I'll release a patch today!

[rvanlaak]

You're doing a great job @soyuka 👏 We have until Nov 27th when 7.4/8.0 will be released in Amsterdam 😉

Were you actually involved in symfony/symfony#61500 and ObjectMapper not being experimental anymore? Also, has extension be discussed, given https://symfony.com/doc/current/contributing/code/experimental.html

I see that the dev-dependency on symfony/object-mapper in the 4.2.3 patch version is bound to the component's 7.4 dev version: https://github.com/api-platform/core/blob/main/composer.json#L186 since #7300

What about

1. Both lowering and widening that to symfony/object-mapper dev dependency to ^7.3|^8.0.
2. Add a "if interface exists" method where ObjectMapperAwareInterface is used, making it up to userland to update their deps to Symfony 7.4 once it lands.
3. Imo the existing wiring in APIP and it's object mapper provider/processor can stay as is as they don't use the interface
4. Rely on composer --prefer-lowest testing in CI for the ObjectMapperAwareInterface dependency

Or even make symfony/object-mapper:^7.4|^8.0 a hard dependency now it isn't experimental anymore, and target version bumps to APIP's upcoming minor?

[soyuka]

Were you actually involved in symfony/symfony#61500 and ObjectMapper not being experimental anymore? Also, has extension be discussed, given symfony.com/doc/current/contributing/code/experimental.html

Of course but we don't want to have an experimental component in an LTS version. What would've been possible (but too late now) is to postpone the component to 8.0 and then to be able to have 3 minor versions to experiment. It was already hard enough to merge a new component and I prefer that it got merged in 7.3 :).

Indeed the changes are done inside #7531 and I'll definitely bump to 7.4 when it's out.

[andreasferber]

Unfortunately the if-condition in the fix is the wrong way around, so it still doesn't work with ObjectMapper 7.3.