A POST on a ApiResource with messenger: true, output: false raise an error 400 with message Unable to generate an IRI for the item of type... in some case :
when no identifier is sent in the request body
when using an async transport
This is working fine in 3.2.* and should not happened as we expect no output (there is no need to generate an IRI).
How to reproduce
With this resource and configuration:
namespace App\ApiResource;
use ApiPlatform\Metadata\ApiResource;
use ApiPlatform\Metadata\NotExposed;
use ApiPlatform\Metadata\Post;
#[ApiResource(operations: [
new NotExposed(),
new Post(status: 202, output: false, messenger: true)
])]
class Foo
{
public ?int $id = null;
}
Doing a POST with an empty body {} on /foos throw an error 400 Unable to generate an IRI for the item of type \"App\\Entity\\Foo\"
Possible Solution
There is a need to check before trying to generate an IRI that we actually expect an output. However, with the new architecture based on processors, I don't know where it would be the more appropriate.
Additional Context
I have been able to track the origin of the problem to this commit. The issue is due to the change of behaviour in WriteListener.php:
in ^3.3, the WritePRocessor is called and $data is retrieved from there and passed to processors until the RespondProcessor is called and try to generate an IRI (L.111)
in 3.2.*, we ensure we need an output before generating the IRI (L.114)
API Platform version(s) affected: ^3.3
Description
A POST on a ApiResource with
messenger: true, output: false
raise an error 400 with messageUnable to generate an IRI for the item of type...
in some case :This is working fine in 3.2.* and should not happened as we expect no output (there is no need to generate an IRI).
How to reproduce
With this resource and configuration:
Doing a POST with an empty body
{}
on/foos
throw an error 400Unable to generate an IRI for the item of type \"App\\Entity\\Foo\"
Possible Solution
There is a need to check before trying to generate an IRI that we actually expect an output. However, with the new architecture based on processors, I don't know where it would be the more appropriate.
Additional Context
I have been able to track the origin of the problem to this commit. The issue is due to the change of behaviour in WriteListener.php: