Symfony version(s) affected

6.4, 7.2

Description

In#51092 theScheduledStamp was made Sendable, so that it is now passed along with theRedispatchMessage to the target transport.

This is okay, however it seems it implies anycustom trigger needs to be serializable, otherwise dispatching it to the transport fails.

For now, I have worked around this by replacing the trigger in the ScheduledStamp with a 'dummy' one that is serializable using an event listener onSendMessageToTransportsEvent event, however I was wondering if Custom Triggers should be completely incompatible withRedispatchMessage?

How to reproduce

1. Create a custom trigger with a non-serializable field (e.g. an empty \Closure or a Service class)
2. Configure a RecurringMessage with said trigger, wrapped in aRedispatchMessage:

return (newSchedule())            ->add(                RecurringMessage::trigger(newUnserializableTrigger(function () => {}),newRedispatchMessage(newMyMessage(),'myTransport')                )            );

3. Runbin/console messenger:consume scheduler_<name>
4. Results in an error such as:

Error thrown while handling message Symfony\Component\Messenger\Message\RedispatchMessage. Removing from transport after 0 retries. Error: "Handling "Symfony\Component\Messenger\Message\RedispatchMessage" failed: Cannot serialize <blabla>" ["class" => "Symfony\Component\Messenger\Message\RedispatchMessage","retryCount" => 0,"error" => "Handling "Symfony\Component\Messenger\Message\RedispatchMessage" failed: Cannot serialize <blabla>","exception" => Symfony\Component\Messenger\Exception\HandlerFailedException^ { …}]

Possible Solution

One obvious option is to not serialize thetrigger object into the ScheduledStamp (not entirely sure how/if the trigger itself is used on the transport side?)

Additional Context

No response