Hey!

Thanks for your PR. You are targeting branch "7.1" but it seems your PR description refers to branch "6.4".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

Not sure what to do with the tests sinceFrameworkBundle tests now depend on the unreleased/unmerged Scheduler version (this PR).

While you're addressing this, could you check other__toString scheduled messages?RedispatchMessage is also affected.

While you're addressing this, could you check other__toString scheduled messages?RedispatchMessage is also affected.

@alex-dev butRedispatchMessage uses the wrapped message's__toString() and it does include the transport names in __toString so I don't think it's affected itself directly?

Or yeah if you don't implement__toString in your message, then it is affected indeed. But since right now__toString is how you define uniqueness, I would consider that a feature and not a bug.

You don't define uniqueness only by__toString. If a message doesn't implement a__toString,Schedule useserialize. So, if a message wrapped by aRedispatchMessage is notStringable, they should be serialized to determine uniqueness.RedispatchMessage should be transparent for identifying uniqueness.

Ok then, I separated id & description and used hashed serialized message for uniqueness withStaticMessageProvider.

I would've rather added explicitgetDescription() onMessageProviderInterface but with optional__toString we should be able to avoid dealing with BC.

What do you think?

We could also consider addingid parameter to#[AsPeriodicTask] &#[AsCronTask] attributes in case someone would rather have static ids which don't depend on message content.

Seems good!

Thank you@valtzu.