CODEWITHSUNDEEP
phpsymfonysymfony4api-platform.com
Asur
Asur

Reputation: 4027

"Unable to generate an IRI for the item of type" exception after api-platform minor version update

I've stumbled upon a problem while updating my dependencies and I wonder if anyone has any clue about what is going on...

I've narrowed down the cause to something related with api-platform and symfony/routing dependencies.

The versions were:

api-platform/core                       v2.3.0
symfony/routing                         v4.1.3

and after the update:

api-platform/core                       v2.4.6
symfony/routing                         v4.1.12

The error is:

{
    "@context": "/api/v1/contexts/Error",
    "@type": "hydra:Error",
    "hydra:title": "An error occurred",
    "hydra:description": "Unable to generate an IRI for the item of type \"App\\Entity\\LeadRequest\"",
    "trace": [
        {
            "namespace": "",
            "short_class": "",
            "class": "",
            "type": "",
            "function": "",
            "file": "/var/www/html/vendor/api-platform/core/src/Bridge/Symfony/Routing/IriConverter.php",
            "line": 133,
            "args": []
        }
    [...]

The entity looks like:

/**
 * Class LeadRequest
 * @package App\Entity
 * @ApiResource(
 *     collectionOperations={"post"},
 *     itemOperations={
 *         "get"
 *     }
 * )
 * @ORM\Entity(repositoryClass="App\Repository\LeadRequestRepository")
 * @ORM\Table(name="lead_request")
 */
class LeadRequest

Of course, I've done my googling diligence and I found several posts about the same error, but I've tried their solutions and are not working. To take some out of the way:

Routing order looks just fine:

------------------------------------------- -------- -------- ------ ---------------------------------------------- 
Name                                        Method   Scheme   Host   Path                                          
------------------------------------------- -------- -------- ------ ---------------------------------------------- 
api_entrypoint                              ANY      ANY      ANY    /api/v1/{index}.{_format}                     
api_doc                                     ANY      ANY      ANY    /api/v1/docs.{_format}                        
api_jsonld_context                          ANY      ANY      ANY    /api/v1/contexts/{shortName}.{_format}        
api_lead_requests_post_collection           POST     ANY      ANY    /api/v1/lead_requests.{_format}               
api_lead_requests_get_item                  GET      ANY      ANY    /api/v1/lead_requests/{id}.{_format}

The entity id getter is accessible:

    /**
     * @var \Ramsey\Uuid\UuidInterface
     *
     * @ORM\Id
     * @ORM\Column(type="uuid", unique=true)
     * @ORM\GeneratedValue(strategy="CUSTOM")
     * @ORM\CustomIdGenerator(class="Ramsey\Uuid\Doctrine\UuidGenerator")
     */
    private $id;

    [...]

    /**
     * @return mixed
     */
    public function getId()
    {
        return $this->id;
    }

Upvotes: 1

Views: 3939

Answers (2)

Pada
Pada

Reputation: 174

That kind of identifiers are not allowed by default, only "incremental ids".

But you could add your own Identifier normalizer (https://api-platform.com/docs/core/identifiers/#custom-identifier-normalizer)

Or even more, your custom Data Provider.

Upvotes: 0

Asur
Asur

Reputation: 4027

After some debugging and research it seems that the problem was caused by a wrong persist() method on the entity DataPersisterInterface implementation.

Basically, the id had null value, so the exception was thrown:

Unable to generate an IRI for the item of type \"App\\Entity\\LeadRequest\

This was happening because the entity was never being saved, so the id was never generated.

Adding the following code to the method implementation solved the problem:

class LeadRequest implements DataPersisterInterface
{
    [...]

    public function persist($data)
    {
        [...]

        $this->em->persist($data);
        $this->em->flush();

        return $data;
    }

    [...]
}

I still don't know why the tests were green on previous versions of the library.

I will edit this answer if I find further information about the subject.

Upvotes: 3

Related Questions