Lazy loaded Swift_Message can cause unserialize errors when using file spool

[mekras]

When storing message in file it will be serialized with class name like Swift_Message_000000003b027a18000000005cb90b1f. After container rebuild this name will change. So if cache was cleared after message stored but before swiftmailer:spool:send command executed there will be error Catchable Fatal Error: Argument 1 passed to Swift_Transport_MailTransport::send() must implement interface Swift_Mime_Message, instance of __PHP_Incomplete_Class given.

This is a rare but troublesome case.

[mekras]

How about adding option to disable lazy loading here?

[Seldaek]

Do you want to send a PR for it? I don't see a problem with making it optional, although it would be nicer if it was fixed upstream.. I find it strange that such classes end up in the spool. I would think the lazy loading is just delaying the creation until we use the message, but once it is sent to Swift it should really store it in a way that can be reloaded not based on the cache settings :/

[mekras]

OK, I'll try.

[mekras]

@Seldaek wrote:

I would think the lazy loading is just delaying the creation until we use the message

Yes, for this purpose a proxy class with a random name is created instead of Swift_Message class. I think this is not an upstream problem but a reasonable solution.

To keep Swift_Message lazy its descendant in MonologBundle can be created with custom serialization method. Method can check for VirtualProxyInterface on $this and return serialization of the real message object, not his proxy. It's quite cumbersome but how about this?

[mekras]

PR to add "lazy" option: #132

[Seldaek]

I can merge your PR as a workaround but I think the proxy class created by symfony should handle serialization gracefully (i.e. instantiate itself fully at that point and then serialize the instance). Or did I misunderstand you? Still sounds like something that could be fixed in symfony.

[stof]

@Seldaek the problem is that serialize($object) will always register the class of the object being serialized, and reuse the same class on unserialization. And this is outside the control of the object.

so the class must exist again to deserialize. The only way to change that would be to change the calling code to stop using PHP serialization

[Seldaek]

Oh right that sucks. I merged the workaround PR then. I guess it should be in the docs that if not using the memory spool people should disable lazy logging as well? Or did I misunderstand that?

cc @RyanWeaver

[xabbuh]

I doubt @RyanWeaver has anything to say here. :)

/cc @weaverryan

[xabbuh]

see symfony/symfony-docs#5596

[lyrixx]

I'm going to close this issue as we can not dot anything here.
The class should exist in the code base to be able to unserialise it.
But @xabbuh added a not in the documentation symfony/symfony-docs@f20fd8d

Thanks