Call to member function getType() on null

[dylanjacob]

I have had this error pop up multiple times doing multiple activities, but in particular I see this issue when trying to add parts to a project. I added some (say 7 for the sake of example) parts and saved the project, but when I try to add additional parts and save the changes to the project I receive an error "Call to member function getType() on null".

Looking at the details, it looks like a request to PUT /api/projects/1?_dc=1453743452067 results in a 500 response.

Related apache2 logs:

[Mon Jan 25 09:44:47.181971 2016] [:error] [pid 33018] [client <ip redacted>:59881] PHP Notice:  Undefined offset: 0 in /var/www/PartKeepr/vendor/dunglas/api-bundle/JsonLd/Serializer/ItemNormalizer.php on line 241, referer: https://<hostname redacted>/
[Mon Jan 25 09:44:47.182221 2016] [:error] [pid 33018] [client <ip redacted>:59881] PHP Fatal error:  Call to a member function getType() on null in /var/www/PartKeepr/vendor/dunglas/api-bundle/JsonLd/Serializer/ItemNormalizer.php on line 241, referer: https://<hostname redacted>/

It looks like the issue is related to a dependency (github: dunglas/DunglasApiBundle). From what I can tell there are no open bugs with that project that sound similar, so this may be better suited for that project, but I wanted to post here as well to see if anyone had any ideas.

[Drachenkaetzchen]

Can you reproduce the issue on demo.partkeepr.org ?

[dylanjacob]

Yes. When I create a project, add some parts and save the project, then add some more parts (even just 1) and attempt to save again I get the error.

[dylanjacob]

This looks like a issue with the dunglas/api-bundle package. Will create issue and potential PR with that project.

[Drachenkaetzchen]

I'd like to keep this issue open for tracking if that's OK with you.

[dylanjacob]

That's fine, I'll reopen.

I think I found (part of) the issue though.

On line 241 of dunglas/api-bundle/JsonLd/Serializer/ItemNormalizer.php:

$type = $attributesMetadata[$attributeName]->getType();

$attributeName == null and so getType is acting on a null value.

[vmw]

I can confirm this issue; as it happens - and I just found this issue by googling the ItemNormalizer file.

My partskeeper log file shows;

[2016-01-27 19:55:10] php.CRITICAL: Fatal Error: Call to a member function getType() on null {"type":1,"file":"/home/parts/vendor/dunglas/api-bundle/JsonLd/Serializer/ItemNormalizer.php","line":241,"level":6143,"stack":[]} []

Also of note might be this conversation of the issue;
https://www.bountysource.com/issues/25457381-type-not-getting-inheritdoc-data

Any workarounds would be greatly appreciated; I'm trying to troubleshoot the issue now, as we're trying to add new files to the project.

[dylanjacob]

I'm playing with updating line 229 to something like

if ('@' === $attributeName[0] || is_null($attributeName[0])) {
    continue;
}

This seems to work cleanly, at least for this application.

[dylanjacob]

I've submitted a pull request to dunglas/DunglasApiBundle with the previously described change. Hopefully it will get it merged soon.

[vmw]

I can confirm that your modification works. In the event it's not accepted upstream, I suggest we patch the version shipped with Partskeepr with the above modification.

[dylanjacob]

So, what I'm seeing is that when a project is saved, the HTTP request is sending something like this JSON:

{
...
parts: {
    0: {
        ...
        project: {
            0: "/"
        },
        ....
    },
    ...
}

It seems that 0: "/" is where the error happens. All of the other parameters before the first part get processed without any problem, but as soon as the denormalize function hits this key, it reads the attribute name as null.

[vmw]

How does partskeepr interpret that string? If it's interpreting the slash as an escape sequence, perhaps that would explain the error?

[Drachenkaetzchen]

Well the serialized JSON is simply plain wrong at this point. This looks suspiciously like api-platform/core#285

[dylanjacob]

@vmw That might work if you download the zip/tarball, but for those using the git method it will not work since the dunglas/DunglasApiBundle package is a managed dependency and it is installed directly from the dunglas/DunglasApiBundle git repo when a user runs composer install. The only real solution is to get it fixed at it's source.

[Drachenkaetzchen]

No worries, we'll find a solution. Dunglas is pretty nice. I will see if I can find the root cause of the issue this weekend, sorry I can't make it earlier.

[dylanjacob]

I've been digging around as well trying to 1) learn more about the PartKeepr codebase and 2) figure out what is really happening behind the scenes.

Thanks for looking into this.

[Drachenkaetzchen]

You're welcome. If you have any more insights that would be helpful.

One thing you could try is to return an empty array in Parts.php method getProjects(), maybe that's the problem.

[fulcrum3d]

Any new progress, Felicitus?

[Drachenkaetzchen]

@fulcrum3d not yet, the security release from yesterday had the highest priority.

[vmw]

To follow up:

In addition to dylanjacob patch, we are encountering similar issues:
2016/02/18 08:26:47 [error] 32469#0: *38536 FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to a member function getName() on null in /REDACTED/src/PartKeepr/PartBundle/Entity/Part.php on line 816" while reading response header from upstream, client: REDACTED, server: REDACTED, request: "GET /api/parts?_dc=1455812807078&page=1&start=0&itemsPerPage=50&group=%7B%22property%22%3A%22categoryPath%22%2C%22direction%22%3A%22ASC%22%7D&order=%5B%7B%22property%22%3A%22category.categoryPath%22%2C%22direction%22%3A%22ASC%22%7D%2C%7B%22property%22%3A%22name%22%2C%22direction%22%3A%22ASC%22%7D%5D HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/php-fpm.sock:", host: "REDACTED", referrer: "REDACTED"

This issue was addressed in a manner similar to the previous one:

I modified line 816 in /src/PartKeepr/PartBundle/Entity/Part.php;

816c816,818
<             $projectNames[] = $projectPart->getProject()->getName();
---
>       if ( $projectPart->getProject() !== null) {
>               $projectNames[] = $projectPart->getProject()->getName();
>       }

This seems to overcome subsequent errors in that form.

I think it would probably be a good idea to do better null checking all around.

As an aside, I am a bit concerned about the integrity of our database, given that we've implemented a couple of patches. Is there a mechanism to easily import and export a given BoM?

[Drachenkaetzchen]

The root cause for this issue is that the ExtJS Hydra/JSON-LD deserializer does currently not support IRIs.

The backend sends an IRI, example:

{
    "project": "/~felicitus/PartKeepr/web/app_dev.php/api/projects/12",
    "quantity": 4,
    "remarks": ""
}

The relation for "project" would be an object, not a string. As such, invalid data is stored and returned in an invalid manner when sending back to the backend.

This is not an issue with DunglasApiBundle.

[Drachenkaetzchen]

I have to apologize for not having a bugfix yet; the underlying issue is more complex than I have anticipated. I hope to provide a bugfix in the next few weeks, but it heavily depends on my workload.

[DTFUHF]

I'm having this issue even in v1.0.0-alpha.1, please let me know if there's any info I can provide to you.

[Drachenkaetzchen]

@DTFUHF first make sure that the issue is actually the same, and not only the same error message. Then please open a new issue with exact error details and preferably steps to reproduce on demo.partkeepr.org