What ProcessInboxCommand is publishing into the _mediator bus?

[1304654]

I can't debug the project so what tyes of INotifications are executed into the bus, inside ProcessInboxCommandHandler?

var messageAssembly = AppDomain.CurrentDomain.GetAssemblies()
          .SingleOrDefault(assembly => message.Type.Contains(assembly.GetName().Name));

      Type type = messageAssembly.GetType(message.Type);
      var request = JsonConvert.DeserializeObject(message.Data, type);

      try
      {
          await _mediator.Publish((INotification)request, cancellationToken);
      }

Is mediator.publish only handle IntegrationEvents only for convert them into InternalCommands or it handle other types of INotification? What other types it handles?? So what diference are between InboxHandler and InternalCommandHandler?

[LukasKuchta]

You need to be aware of reliability concept. Save, send and execution are three diffrent parts.

[Save] There is a hooked a generic handelr on event bus where event's appearence is stored into database (metadata + type of this event). I'm sure that message was recieved by my module. End of first part of story.

[Send] Second part is Inbox job processing where handler creates Integration event based on (metadata + type) from first part and send this message. Inside the handler of this message is transformation IntegrationEvent -> Command via scheduling. I'm sure that message was send inside my module. End of second part of story.

[Execution] Last part of story is Internal command processing read those commands and trying to execute them. During the execution is present retry mechanism for resilience. When command handler ends without error long story is on the end.

Each of those parts has its own responsibility inside the transaction scope.
[SaveTransaction] - convert and save message into db. No additionl logic here.
[Sendransaction] - send message, check status and save into db. Handler only schedule another work. No additional logic here.
[ExecutionTransaction] - one trasnaction for tracing commands processing (read and save state) and another for each

command via commandExecutor where is created own transaction scope (own db context and saveChangesAsync()) per execution. There is no one transaction for bulk execution. So there is guarantee that each command handler has its own transaction. Like executing via API (sending command manually). ASP has request transaction scope and this is IMPORTANT for internal commanding.

[IntegrationEvent recieved] -> [integrationEvent send] -> [IntegrationEvent executed]