fix(symfony): context not serializable when session

[MariusJam]

Q	A
Branch?	3.1
Tickets	Closes api-platform/api-platform#2611
License	MIT

In some case, a "Serialization of 'Closure' is not allowed" Exception is thrown when using Messenger. This is due to the fact that the $context array is passed to the Envelope via the ContextStamp and that $context['request'] is set with a not serializable Request object.

Symfony does not guarantee that a Request is serializable so the best solution would be to completely unset $context['request'] in the ContextStamp. However this would be a breaking change. So, I'm proposing an alternative solution by unsetting $context['request'] only when the Request object has a session as it seems to be the identified buggy case.

[soyuka]

Interesting, can't this be fixed in Symfony? Is there a way to set a serializer context when using messenger?

[MariusJam]

can't this be fixed in Symfony?

I was wondering as well. I asked in Symfony's Slack support channel and the answer was : "Symfony does not guarantee that the Request object is serializable. So passing that in a messenger enveloppe will indeed not work. API-Platform should be careful about that". Hence the PR here.

Is there a way to set a serializer context when using messenger?

It might be possible but that would require to change the Messenger's default configuration. According to Symfony' doc, the serialization/deserialization of messages use the php's serialize() and unserialize() functions by default, not the Serializer component.

I guess changing this default behaviour could be possible but this would be a more major change...

[soyuka]

I'm afraid that other parts of the request would be unserializable (we have closures in its attributes sometime). What about removing request alltogether? Another concern is that it could break current implementations, maybe that we should put this on the main branch instead? (expect a release this month)

[MariusJam]

Yes that's the risk indeed. That's why I was proposing to already fix the case on 3.1/3.2 branches, but only when there is a session : we know it creates a bug so we should not break anything as it already fails, or I'm missing something 🤔

On the main branch, I can indeed make another PR to completely remove the request.

Would you be okay with that or you prefer just a PR on the main branch?

[soyuka]

👍 I fixed the CI on 3.1, I'll re-run your tests after and if all green I merge, expect a release following that