I don't know if I really understand the PR but it is weird to dispatch event in handlers. Normally, you should dispatch event after committing the main transaction. Then, you can dispatch all events raised by your domain object (entity) and subscribe them.

Example:

class User {private$messages = [];publicfunction__construct()    {$this->messages[] =newUserRegistered(/*...*/);    }publicfunctionmessages()     {return$this->messages;    }}// It should be wrapped into a transactionclass RegisterUserHandler{publicfunction__invoke(RegisterUser$command)    {$user =newUser(/*...*/);// If we use a collection oriented repository, events can be collected in a middleware. In the unit of work, you can find the aggregate User and get all messages.$this->userRespoitory->add($user);// If we use a collection oriented repository, you don't have a unit of work so your repository need to collect them.$this->userRespoitory->save($user);    }}class DispatchEventMiddleware{publicfunctionhandle(/*...*/)    {// Your transaction has been committed then your dispatch your event    }}

Perhaps,$this->messageBus->dispatch(/*...*/) should not dispatch event/message synchronously?

@Nyholm : I gave this a shot in userland. This just needs some tweaks to comply the 4.2 Messenger interfaces (and sharing the same middleware instance across buses (#28849 (comment))), but it works great!
I'm not sure about the terms used, though. Transaction may be a bit confusing with the doctrine transaction middleware. No strong opinion, maybe I'm just used to thelock term in use with Tactician.

Tell me if you want some help to take over.

Thank you for testing this.

Yes, please. This has been on my TODO list for ages now. Please help me.
I will try to fix this during the holidays but if you (or someone) have time before that, feel free.

I've pushed new changes and tests, trying to showcase a bit the feature in it.
I may have a look at the docs, too.

Status: Needs Review

I have tried implementing this in userland with a test app and I can not figure out how to dispatch between buses. I have a command bus that is trying to dispatch to an event bus using the Transaction stamp. In mymessenger.yml I have the transaction middleware declared for both buses. Is there something else I need to configure? My service for the middleware is declared withabstract: false as I saw the comment that otherwise separate middlewares would be generated.

I've rebased this PR on master.
Status: Needs Review

@gubler Did you add theHandleMessageInNewTransactionMiddleware before the Doctrine transaction middleware?

@Nyholm Yes, I did. I have createda test project here that you can review and see if I messed anything up.

I'm guessing its more likely I've made an error in the config or usage.

@gubler : It seems you only declared thehandle_message_in_new_transaction middleware on command bus:https://github.com/gubler/messenger-transaction-test/blob/54b225f5df9a68a502d8e74d7acbcba2c4da94e5/config/packages/messenger.yaml#L9

Which means the event you dispatch from the command handler to the event bus won't go through the middleware queuing it, so it's dispatched directly.

You must declare it on each bus likely to have messages they handle queued by a transaction. Which means your event bus here.

@ogizanagi I added the middleware to the event bus:https://github.com/gubler/messenger-transaction-test/blob/master/config/packages/messenger.yaml

Now theBookCreatedSubscriber does not execute at all, whether theNewBookHandler succeeds or errors.

@gubler: 😱 There was indeed an issue! The wrong$stack was passed to the next middleware when resuming dispatching the queued items. Which means the handler middleware was not called, as the middleware stack used was empty (because the main dispatch call's stack was used).

Thanks for testing this and for the reproducer btw.
Could you give a try to the last commit? 🙏

Merged your changes intomy test app and it looks like everything works now!

Thank you very much for figuring this out 🎉

You guys are the best. Thank you@gubler and@ogizanagi to testing and fixing this PR.

Thank you. I've updated the PR according to@weaverryan's suggestions and I've rebased to avoid the merge conflict.

Minor conflict now oncomposer.json file.

Still +1 from me

I fixed the conflict

Please squash commits.

Thank you for the reviews. I've squashed my commits

Thank you@Nyholm.

Thank you for merging