Symfony version(s) affected

6.4, 7.2

Description

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

This is okay, however it seems it implies any custom 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 on SendMessageToTransportsEvent event, however I was wondering if Custom Triggers should be completely incompatible with RedispatchMessage?

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 a RedispatchMessage:

return (new Schedule())
            ->add(
                RecurringMessage::trigger(
                    new UnserializableTrigger(function () => {}),
                    new RedispatchMessage(new MyMessage(), 'myTransport')
                )
            );

3. Run bin/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 the trigger object into the ScheduledStamp (not entirely sure how/if the trigger itself is used on the transport side?)

Additional Context

No response