Broken behavior processing operations with defined 'output' class

[Perf]

Hello,
an exception is thrown when processing request by WriteListener.php.
At line 81 there is a call to get Iri from object of output class. But, obviously, it's not always possible, as the output class could be another object rather than ApiResource.

if ($hasOutput) {
    $request->attributes->set('_api_write_item_iri', $this->iriConverter->getIriFromItem($controllerResult));
}

Exception:

No item route associated with the type "Lexik\Bundle\JWTAuthenticationBundle\Response\JWTAuthenticationSuccessResponse" at /srv/api/vendor/api-platform/core/src/Bridge/Symfony/Routing/RouteNameResolver.php line 62

Here is a sample configuration of a custom operation:

    collectionOperations:
        confirmation:
            method: 'POST'
            path: '/users/confirmation'
            access_control: 'is_anonymous()'
            messenger: 'input'
            input: 'App\Entity\User\Input\UserConfirm'
            output: 'Lexik\Bundle\JWTAuthenticationBundle\Response\JWTAuthenticationSuccessResponse'

Some additional notes:
There was a related issue #2550 that was fixed with #2628.
It worked for a while... and seems to be was 'broken' with: 433ce07#diff-3bc4e0ec1a3570f4deb961f3652800a6
So, now $hasOutput gets true at line 77, because now $controllerResult is an instance of $outputMetadata['class']

core/src/EventListener/WriteListener.php

Line 77 in 125dec9

$hasOutput = \array_key_exists('class', $outputMetadata) && null !== $outputMetadata['class'] && $controllerResult instanceof $outputMetadata['class'];

which it totally correct... but this leads to improper call of

core/src/EventListener/WriteListener.php

Line 81 in 125dec9

$request->attributes->set('_api_write_item_iri', $this->iriConverter->getIriFromItem($controllerResult));

Imho, at line 80 it's necessary to add additional check, if object in $controllerResult is an "ApiResource" object.

[dunglas]

@Perf good catch. A cleanest patch would be to pass the resource object related to the DTO to be able to populate this attribute. Would you want to work on a patch?

[Perf]

hey @dunglas,
yep, I could try to develop it. But need to clarify a few details.

• Why do we need to get an item Iri for a case when we respond with an object that is not (completely) related to any of Api Resources?

What we have in current config:

• input class is a kind of DTO that is related to api resource, but not really explicitly, as the only place that "links" this DTO with Api Resource is a yaml config of an Api Resource, where DTO class is stated as input class for a specific operation.
• output class is a completely not related object to any of api resources

So, as it seems, it should be possible to get an item Iri from $resourceMetadata and $outputMetadata.

core/src/EventListener/WriteListener.php

Lines 75 to 76 in 125dec9

	$resourceMetadata = $this->resourceMetadataFactory->create($attributes['resource_class']);
	$outputMetadata = $resourceMetadata->getOperationAttribute($attributes, 'output', ['class' => $attributes['resource_class']], true);

My assumption is correct?

Update:
Looked into $resourceMetadata at runtime:

Obviously, there is no reference to Api Resource object, also Iri is not set.
@dunglas why do we need to set item iri for a response with the object which is not related to an api resource?

[teohhanhui]

_api_write_item_iri is used for setting the correct HTTP response headers: https://github.com/api-platform/core/blob/v2.4.3/src/EventListener/RespondListener.php#L65-L71

But yeah, I don't think we could make correct assumptions for all custom operations.

[teohhanhui]

Also, the iri in ResourceMetadata is not related to the item IRI. That's actually the IRI of the type, e.g. https://schema.org/Book

[Perf]

_api_write_item_iri is used for setting the correct HTTP response headers: https://github.com/api-platform/core/blob/v2.4.3/src/EventListener/RespondListener.php#L65-L71

But yeah, I don't think we could make correct assumptions for all custom operations.

hey @teohhanhui
thanks for clarification... and yes - here is a big question - if it's really mandatory to set _api_write_item_iri?
As for the subject case - it's seems to be absolutely nonsense.

[olivermack]

Actually I'm currently trying to get the head around this issue as well. I'm just curious why it should be absolutely mandatory to set the request attribute _api_write_item_iri at all - I mean, why not simply wrapping this portion in a try/catch?

An alternative could probably be to provide some sort of resource metadata which the WriteListener can utilize to determine if a result-iri should be obtained at all.

In my case I'm using the messenger to dispatch domain commands - in this very case handling GraphQL. The issue pops up as soon as you turn off the output (yah, I don't need to rely on synchronous processing with result here) - at least in the current master (did not compare with latest release 2.4.3) the generated GraphQL schema is invalid because each Resource, even if it's a empty-response command DTO, needs to have fields... if not, GQL clients error with something like Type MySampleCommand must define one or more fields (via Apollo) or MySampleCommand fields must be an object with field names as keys or a function which returns such an object. (via GraphiQL).

[teohhanhui]

Should be fixed by #2910