Hi @emaarco,
in my point of view, you have a similar issue with the worker too.
Consider the following diagram:
If something goes wrong with completing the job, you will have to deal with it.
You have the same challenge with systems like Kafka. So, how do you handle this? You cannot put the out port in the same transaction. Things can also go wrong when committing the DB transaction, e.g. optimistic locking. You then cannot rollback the remote changes. As you have described well, it also leads to problems that the outgoing events / commands are already processed before the state is actually committed.
I’m actually not so sure about the solution here. If we suppose that the engine is a highly available system, we can assume that the commands are accepted by the engine for Process Start and Send Message. Therefore, in my opinion, you can skip the outbox pattern.
If you also already have a system like Kafka in use, you could also send commands (after transaction) to yourself and process them asynchronously. But what would be the difference between sending it to the engine straight away? Any external system that you call after the transaction carries the risk that the action will fail. This also applies to a database in which the outbox pattern is mapped.