You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We enabled to have multiple #[Subscribe(Event::class)] in one Subscriber when we added the feature to listen to all events with * notation, see here. This leads to the situation that the subscription engine cannot work 100% perfectly. What does that mean? If a Subscriber listens to one Event with multiple methods it can lead to unwanted actions. Let's take this Subscriber as an example:
#[Projection('order')]
class OrderProjection
{
// ...
#[Subscribe(OrderSubmitted::class)]
publicfunctionsendConfirmationMail(OrderSubmitted$event): void
{
// send mail
}
#[Subscribe(OrderSubmitted::class)]
publicfunctionupdateOrderInReadModel(OrderSubmitted$event): void
{
// write to read model
}
}
The described Subscribe may be defined as an antipattern here, as it is talking to 2 different systems here, but this is not the point of the Issue.
Now, if one of the 2 methods is failing, like e.g. the DB is not reachable, then the projection fails, which is normally no problem. But in this case, we dont know - or better the subcription engine does not know - which of these 2 methods failed. Since they are both listening on the same event the position is not helpful here. The result is, that both of these methods will be called again when retried. That could lead to either sending the same mail multiple times or corrupting the database with maybe false information if we are doing additive/mathy operations.
As I mentioned earlier: IMHO this situation would not occur if the software design would be better here in the application. So you could argue it is not a big issue then. But I can also not think of an valid usecase to allow this subscriber configuration. So I think we should not allow it at all.
Does it affect * notation? Yes, I think so, since we would have the same problem again if the have a method on the subscriber which listens on all events and some dedicated methods which are listening to some events. We would encounter the exact same problem again.
So my idea would be to disallow listening to the same event multiple times in a subscriber. As soon a subscriber listens to all events via * it cannot have other methods listening to any event.
The text was updated successfully, but these errors were encountered:
As I already mentioned that I cannot think of an valid usecase for this behaviour I think that we should fix it 3.x and not in our next major despite being a BC-Break. The risk is just too high that this might disrupt a production system.
We enabled to have multiple
#[Subscribe(Event::class)]
in one Subscriber when we added the feature to listen to all events with*
notation, see here. This leads to the situation that the subscription engine cannot work 100% perfectly. What does that mean? If a Subscriber listens to one Event with multiple methods it can lead to unwanted actions. Let's take this Subscriber as an example:The described Subscribe may be defined as an antipattern here, as it is talking to 2 different systems here, but this is not the point of the Issue.
Now, if one of the 2 methods is failing, like e.g. the DB is not reachable, then the projection fails, which is normally no problem. But in this case, we dont know - or better the subcription engine does not know - which of these 2 methods failed. Since they are both listening on the same event the
position
is not helpful here. The result is, that both of these methods will be called again when retried. That could lead to either sending the same mail multiple times or corrupting the database with maybe false information if we are doing additive/mathy operations.As I mentioned earlier: IMHO this situation would not occur if the software design would be better here in the application. So you could argue it is not a big issue then. But I can also not think of an valid usecase to allow this subscriber configuration. So I think we should not allow it at all.
Does it affect
*
notation? Yes, I think so, since we would have the same problem again if the have a method on the subscriber which listens on all events and some dedicated methods which are listening to some events. We would encounter the exact same problem again.So my idea would be to disallow listening to the same event multiple times in a subscriber. As soon a subscriber listens to all events via
*
it cannot have other methods listening to any event.The text was updated successfully, but these errors were encountered: