This implementation would cause an infinite recursion because the serializer would inject itself as normalizer and dispatch the normalize call to our custom normalizer again.

The infinite recursion can be avoided with this trick:https://symfonycasts.com/screencast/api-platform-security/normalizer-aware#avoiding-recursion-with-a-context-flan

As written in theAPI Platform documentation, this way to do is actually working if adding a flag in the context.

I guess we can close here and open a new PR to documentsymfony/symfony#46625.

@HeahDude Not sure actually :) This example is what prevents us from enabling the serializer panel by default as it builds on an autowired concrete class instead of an interface.

The alternatives I can think of:

• Use the NormalizerAwareInterface as currently proposed (with the suggested context flag trick to avoid recursion)
• Change the parameter type declaration fromObjectNormalizer toNormalizerInterface and add the config needed to make it gets theserializer.normalizer.object service injected

If we are not happy with both approaches, that probably means we need to work on adding a better way to giveObjectNormalizer capabilities to a userland normalizer (e.g. a trait or a more scoped interface)

Thinking twice about this, I'd advocate for the explicit DI approach (second alternative in#16826 (comment))

What should we do with this PR? Merge, close or keep working on it? Thanks!

I think it misses two things:

1. Add a flag in a context to prevent infinite recursions (here, the normalizer will call himself infinitely)
2. Maybe add an example to inject a specific implementation of a normalizer thanks to container configuration (here it'll call the chain normalizer)

At least one of these points should be done to prevent infinite recursion.
Either using a flag or injecting a specific implementation will solve that issue, but IMHO, both of these methods might be documented.

closing as I think this has been fixed in#19532