symfony profiler + subresource breakage on 2.6.0

[yivi]

API Platform version(s) affected: 2.6.0

Description
With the profiler enabled, queries to subresources break, and the profiler information is not saved (a profiler token is generated, but the data is lost.

How to reproduce
Minimal repo demonstrating the issue here:
https://github.com/yivi/api-platform-bug-subresource-profiler

composer create-project symfony/skeleton project
cd project
composer req api
composer req profiler

Created two basic Book and Author entities, with Book -> ManyToOne -> Author, and Author::books marked as subresource:

    /**
     * @ORM\OneToMany(targetEntity=Book::class, mappedBy="author")
     * @ApiSubresource
     */
    private $books;

Trying:

curl -X GET "http://localhost:9898/api/authors/1/books?page=1" -H  "accept: application/ld+json"

I get:
error.log

Possible Solution
Sadly I have no clue. I'll try to dig more tomorrow.

Additional Context
Found out about this mostly because I saw that the profiler data was being disappearing from some requests, which seemed very strange. Going back to 2.5.9 everything works as it should.

[yivi]

Seems to be fixed on 2.6.1

[yivi]

My mistake, I had set the requirements to 2.5.9 to double check the behavior didn't occur in pre 2.6

Retested on 2.6.1, the issue remains:

[raress96]

I think I also have the same issue after updating. But I get the error:
request.CRITICAL: Uncaught PHP Exception Exception: "Serialization of 'Closure' is not allowed" at F:\Coding\PHP\Sites\caut.mesteri\vendor\symfony\http-kernel\Profiler\FileProfilerStorage.php line 175 {"exception":"[object] (Exception(code: 0): Serialization of 'Closure' is not allowed at F:\\Coding\\PHP\\Sites\\caut.mesteri\\vendor\\symfony\\http-kernel\\Profiler\\FileProfilerStorage.php:175)"} [] from the Profiler.

[yivi]

@raresserban Yes, that error is included in the trace attached above.

On Symfony\Component\HttpKernel\Profiler\FileProfilerStorage::175 an attempt is made to serialize ApiPlatform\Core\Bridge\Symfony\Bundle\DataCollector\RequestDataCollector, which ends up triggering that error.

The changes for RequestDataCollector are minimal for this release, so I guess the problem is triggered by a change of behavior up the chain. Only today had some time to dig a bit more, but couldn't find anything definitive yet.

Hoping for someone smarter than me coming along to figure it out. :)

[soyuka]

Indeed this is a really weird issue and kinda hard to debug!

[soyuka]

Can you try my fix at https://github.com/api-platform/core/pull/4023/files?

[burned42]

@soyuka for me that seems to do the trick and my tests are all green with your fix! 🚀

[yivi]

Indeed @soyuka, that does the trick. 🥇