What could also be a cool feature here is addtransports property to both attributes/tags, then if it is set, wrapServiceCallMessage inRedispatchMessage.

This looks nice! I'll give a proper review and help finish up for 6.4 when I have some time.

What are you thinking for commands? I was thinking:

#[AsCronTask(expression:'* * * * *', arguments:'arg --option')]class MyCommandextends Command{}

What are you thinking for commands?

I was hoping we don't need such, as business logic usually is wrapped in a separate class and commands just act as an entry point, just like controllers. But I think this is only my reality.

About the attribute syntax for commands,ArrayInput syntax was my first thought, but I seeRunCommandMessage uses string input so probably your suggestion makes the most sense if the approach would be to produce those instead ofServiceCallMessage. AlsoStringInput syntax is less verbose and since the whole point here is to make thing easier, that's the way to go then.

Looking good! Glad you got commands working - usingRunCommandMessage is exactly what I was thinking.

I didn't realize it's possible to useRedispatchMessage without explicitly defining the transports (and rely onrouting configuration), we need to add support for that also. Probably renametransports toredispatch and allow boolean.

Hmm, ok it does not seem possible after all, if transportNames are not defined, then the message is not dispatched to any transport – unlike the Messenger docs are stating.

Thank you@valtzu.

@valtzu@kbond iiuc, this doesn't support stateful schedules (equivalent to$schedule->stateful($cache)), right?

nvm, it will only add tasks to given schedule (and schedule can be optionally be stateful)