[Serializer] Custom Normalizer broken after upgrading to 6.1

[alexchuin]

Symfony version(s) affected

6.1

Description

My custom Normalizer is broken since i've upgraded to Symfony 6.1.
This problem seems to be related to the new Serializer Profiler.

Maybe I forgot something?

Thanks,
Alex

How to reproduce

Just use this example :

https://symfony.com/doc/6.1/serializer/custom_normalizer.html

Possible Solution

No response

Additional Context

FileNormalizer::__construct(): Argument symfony/symfony#2 ($normalizer) must be of type Symfony\\Component\\Serializer\\Normalizer\\ObjectNormalizer, Symfony\\Component\\Serializer\\Debug\\TraceableNormalizer given

[xabbuh]

Does the issue go away when you change the type-hint of your constructor argument from ObjectNormalizer to NormalizerInterface and does your normalizer still work as intended?

[alexchuin]

Nope, already tried and got a Circular reference detected :

Circular reference detected for service "debug.App\Api\Normalizer\FileNorma !! lizer", path: "debug.App\Api\Normalizer\FileNormalizer -> debug.serializer !! -> debug.serializer.inner -> debug.App\Api\Normalizer\FileNormalizer".

Because ContextAwareNormalizerInterface is deprecated since 6.1 :
@deprecated since symfony/serializer 6.1, use NormalizerInterface instead

Thanks!

[xabbuh]

I changed my suggestion for the update of the documentation a bit. Can you try out the new version in symfony/symfony-docs#16826 please?

[derrabus]

I think that the example from the docs is correct and should continue to work after an upgrade. We should treat this as a bug.

The serializer topic aside: If I autowire a constructor parameter with a Foo type, I find it astonishing that I receive a service that is not a Foo.

[alexchuin]

Yes, thanks all but I just downgraded to 6.0 until it will be fixed :)

[darthf1]

Similar (?) issue. On 6.0, the following service declaration works:
services.yaml

  Infrastructure\Shared\ApiPlatform\Serializer\JsonLdNormalizer:
    decorates: 'api_platform.jsonld.normalizer.item'

use ApiPlatform\Core\Api\IriConverterInterface;
use ApiPlatform\Core\JsonLd\Serializer\ItemNormalizer;
use Symfony\Component\Serializer\Normalizer\CacheableSupportsMethodInterface;
use Symfony\Component\Serializer\Normalizer\DenormalizerInterface;
use Symfony\Component\Serializer\Normalizer\NormalizerInterface;

final class JsonLdNormalizer implements NormalizerInterface, DenormalizerInterface, SerializerAwareInterface, CacheableSupportsMethodInterface
{
    public function __construct(
        private readonly IriConverterInterface $iriConverter,
        private readonly ItemNormalizer $decorated,
    ) {
    }

    ......
}

On 6.1 I suddenly get the error:

Cannot autowire service "Infrastructure\Shared\ApiPlatform\Serializer\JsonLdNormalizer": argument "$decorated" of method "__construct()" references class "ApiPlatform\Core\JsonLd\Serializer\ItemNormalizer" but no such   
  service exists. Try changing the type-hint to one of its parents: interface "Symfony\Component\Serializer\Normalizer\DenormalizerInterface", or interface "Symfony\Component\Serializer\Normalizer\NormalizerInterface". 

If I change my service declaration:

  Infrastructure\Shared\ApiPlatform\Serializer\JsonLdNormalizer:
    decorates: 'api_platform.jsonld.normalizer.item'
    arguments:
      $decorated: '@.inner'

The error message changes:

Infrastructure\Shared\ApiPlatform\Serializer\JsonLdNormalizer::__construct(): Argument symfony/symfony#2 ($decorated) must be of type ApiPlatform\Core\JsonLd\Serializer\ItemNormalizer,  
     Symfony\Component\Serializer\Debug\TraceableNormalizer given

[camilleterol]

I am having the same issue. Let me know if you need any help reproducing this one.

It happens when a Custom Normalizer is autowired with the ObjectNormalizer service.

[stof]

Well, I'm not sure the normalizer services were actually meant to be autowirable based on their class name. Supporting that means that we don't support decorating them (and so that we cannot apply the traceable decorators on them).

To me, the autowirable names in core should only about interfaces for that reason.

[derrabus]

I think, the use case described in the linked piece of documentation is a valid one: We want a normalizer that behaves like ObjectNormalizer mostly, but wee need to change a thing or two in the resulting array.

This is why our custom normalizer requests exactly that implementation of a normalizer. And our custom normalizer may receive an undecorated ObjectNormalizer, that's fine. I doubt that we need that level of traceability.