Delivery behavior, when it's impossible to load Aggregate for some reason (a coding mistake, storage issues, etc.), is unclear. It looks like all commands and events that point to corrupted Aggregate stays in InboxStorage forever. And re-delivered on each shard delivery iteration.
Steps to reproduce:
- Throw an exception in the
@Apply method of the aggregate.
- Send
FirstCommand to the aggregate and emit the event that will lead to the exception.
- Send
SecondCommand to the aggregate and emit the event that will lead to the exception.
- Send one more command with the same
ShardIndex to another entity.
What happens:
- Aggregate failed to apply the event and threw an exception;
- Diagnostic event
CannotDispatchDuplicateCommand thrown for SecondCommand.
What I expect:
- Aggregate failed to apply the event and threw an exception;
Diagnostic event CannotDispatchDuplicateCommand thrown for SecondCommand;- Another entity successfully handles the command.
Delivery behavior, when it's impossible to load Aggregate for some reason (a coding mistake, storage issues, etc.), is unclear. It looks like all commands and events that point to corrupted
Aggregatestays inInboxStorageforever. And re-delivered on each shard delivery iteration.Steps to reproduce:
@Applymethod of the aggregate.FirstCommandto the aggregate and emit the event that will lead to the exception.SecondCommandto the aggregate and emit the event that will lead to the exception.ShardIndexto another entity.What happens:
CannotDispatchDuplicateCommandthrown forSecondCommand.What I expect:
Diagnostic eventCannotDispatchDuplicateCommandthrown forSecondCommand;