-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] Add auto stamp attribute and middleware #50812
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 7.3
Are you sure you want to change the base?
Conversation
Hey! To help keep things organized, we don't allow "Draft" pull requests. Could you please click the "ready for review" button or close this PR and open a new one when you are done? Note that a pull request does not have to be "perfect" or "ready for merge" when you first open it. We just want it to be ready for a first review. Cheers! Carsonbot |
d4e67bc
to
b5a964f
Compare
Maybe it's a stupid idea, but are there arguments against using stamps as attributes directly? #[AutoStamp(new DelayStamp(123))]
#[AutoStamp([new ValidationStamp(['Default', 'Extra'])])]
class AutoStampedMessage
{
} Vs. #[DelayStamp(123)]
#[ValidationStamp(['Default', 'Extra'])]
class AutoStampedMessage
{
} |
b5a964f
to
89fb4e5
Compare
It's done, i'm not sure about second commit |
I think I'm in favor of @derrabus' idea. This allows 3rd party stamps that aren't attributes to be used. |
Interesting. Thank you for this PR.
It is the dispatcher that is smart, it knows how long a message should be delayed. It should not be the receiver nor the message itself. If we add this kind of configuration on the message, how do a dispatcher opt out? Or how can a dispatcher change the config, Say delay for 10s instead of 5s? (think retry middleware). I think we open a can of worms.. What is the reason for adding auto-stamps or adding stamps to the message directly? |
No, the dispatcher should stay dumb. Adding stamps based on attributes (however those might look like) can and should be done by a middleware.
The sttributes on the message should be a default. The retry middleware needs be able to override those defaults.
Yes, it is syntactic sugar for wiring a piece of middleware that always adds the same stamps to a specific message class. |
I see it like defaults too. |
With the current implementation, if I write
and the I would expect the opposite, the attribute should be a "default" but can be overriden when dispatching the message. I just thought/wanted a similar feature and tried to introduce a SelfStampableInterface in |
Add
AutoStamp
attribute on message and configure messenger to enableAutoStampMiddleware
to automatically add stamps on message.No needs to pass them when dispatch message.