Description

Context
Running symfony in a serverless infrastructure, like Google clouds "Cloud Run" works great. One problem is that this architecture does not allow for long running processes, and is instead meant to react to events as HTTP calls. This introduces some issues when working with the messenger component, especially in combination with the scheduler.

The messenger component is intended to work as a pull mechanism. The worker pulls the messages it needs to execute, and runs them. This pull mechanism works very well when you have a long running process ( the worker), which pulls the messages and executes them. In an environment where this is not possible, you are rather limited in your options.

What is currently possible
Using the gps-messenger-bundle, it is possible to use google clouds pubsub as a transport. When configuring this as a push transport, and using the symfony webhook component to accept the messages, we can work with 'normal' messenger messages which are dispatched as if they came form the worker.

Scheduler options
The only real problem seems to be the scheduler component. A workaround would be to check for any scheduled messages when handling any other message. This could be done with the Symfony\Component\Scheduler\Generator\MessageGeneratorInterface. The downside here is that if there are few messages being handled, the schedules may fall behind. I'm also not entirely sure if this would dispatch the same message multiple times.

Another option would be something like Drupals poor mans cron, where during (some/every) request you check for possible scheduled messages is a solution, but it comes with its own downsides.

What am i looking for
If i missed a crucial detail about how this is already easily possible, i'd love to hear it. And if that isn't documented yet, maybe it could be added to the symfony documenation.

If it is not, i'd love to figure out a way to get a way to have push based scheduled messages into symfony. I'd be more than happy to build this feature if this is something that is wanted and possible.
One of the most important parts should be that whether the messages are pulled from a worker, or pushed in another way, the handling of messages, and their events should remain the same.

Example

No response