v3.3.8: Embedded subresources no longer denormalizing

[paullallier]

API Platform version(s) affected: 3.3.8 (works in 3.3.7)

Description
I've got a PUT endpoint like this:

I'm having trouble with the embedded /accounts/{id} IRI in 3.3.8, which I think relates to the changes to IriConverter in #6451.

In 3.3.7, it pulls the account entity from the database fine. In 3.3.8, it fails on this check, which was added in that PR, I think.
https://github.com/ili101/api-platform-core/blob/14cc145ce646fe4a799652f5b451d0140076cf18/src/Symfony/Routing/IriConverter.php#L81

At that point, my $context points to the Tax entity, but it would still find the GET operation for the Account entity in 3.3.7. Now it complains that I have an IRI for the wrong type of resource instead.

I suspect this might be an edge case that the tests are missing? (Or I'm using API-P in an unusual way again...)

[soyuka]

when denormalizing a relation the context should be reset ($context should not point to Tax) can you give me your configuration?

[fvozar]

I have the same issue with 3.3.8.

Operation:

new Post(
	uriTemplate: '/venues/{id}/validate-settings',
	uriVariables: ['id' => new Link(fromClass: Venue::class)],
	status: 200,
	input: ValidateVenueSettingsInput::class,
	output: VenueSettingsValidationOutput::class,
	processor: VenueSettingsValidatorProvider::class,
),

Input DTO:

class ValidateVenueSettingsInput
{

	#[Assert\NotBlank]
	public EmailType $template; // enum

	#[Assert\NotBlank]
	public Language $language; // doctrine entity and API resource

}

The error I got: 'Invalid IRI "/api/languages/018f15ed-e7d1-7c98-a407-3de1522dcd63".'. It was caused precisely by the abovementioned code from paullallier.

[soyuka]

If there's the provider I need a provider to reproduce, can anyone create a minimal repro? Also what's your standard_put value in the configuration?

[fvozar]

During debugging, the code didn't even reach the processor (I have a typo in the class name; it's not the provider). The error occurred during deserializing the input DTO class.

Standard put is set to true. But the operation is POST in my case.

[soyuka]

What's your body during the POST operation? What content-type? I need more to create a reproducer.

[fvozar]

Here is the example repo: https://github.com/fvozar/input-dto-bug/tree/main

There are two entities Foo and Bar. I've created one Foo and two Bar objects.

Then I called endpoint POST /api/foo/1/validate with body

{
  "bar": "/api/bars/2"
}

The IRI with different value for ID is important here, because when I use "bar": "/api/bars/1", it's working. I think it's because the id values match.

Response:

{
  "@id": "/api/errors/400",
  "@type": "hydra:Error",
  "title": "An error occurred",
  "detail": "Invalid IRI \"/api/bars/2\".",
  "status": 400,
  "type": "/errors/400",
  "trace": [],
  "hydra:title": "An error occurred",
  "hydra:description": "Invalid IRI \"/api/bars/2\"."
}

Full curl:

curl -X 'POST' \
  'https://127.0.0.1:8001/api/foo/1/validate' \
  -H 'accept: application/ld+json' \
  -H 'Content-Type: application/ld+json' \
  -d '{
  "bar": "/api/bars/2"
}'

I haven't changed anything special in config, it's new project with Api platform installed.

---

For real-world example in my application I'm using application/ld+json as content type and body is

{"template":"reservationContractCreated","language":"/api/languages/018f15ed-e7d1-7c98-a407-3de1522dcd63"}

[soyuka]

nice thanks, I'll check that out!

[paullallier]

Thanks guys

[soyuka]

can you check my patch (install a dev version of 3.3) and let me know, I'll tag a release shortly if it's alright

[paullallier]

Thank Antoine. It seems to work for me. (I had to apply the patch manually because I was getting dev-main when I asked for 3.3.x-dev, but I think you might have fixed that on packagist already).

No - I've patched 3.3.7 which wasn't broken. I'll run it again.

[paullallier]

It's not working for me because $this->getInputClass($context) returns null, but that might be a config error in the way I've defined my classes?

[fvozar]

Hello @soyuka, I can confirm that your patch works in my case. Thanks a lot 👍

[paullallier]

If I explicitly define input: Tax::class on my Tax entity, it looks like it works for me too. I'm re-running my test suite, which will take a while.

I suspect I might not be the only person this changes catches out though...

[soyuka]

@paullallier can you please give me a stack trace? it must be a similar issue where uri_variables should've been removed from the context but are still available when denormalizing a relation. Basically send me the same details as I asked above so that I can reproduce.