(Deprecation label should be removed BTW)

I think the approach of having a decorated handler might not be the best. What aboutusing a transport for this?

@sroze Not sure if I got it right....is this the right approach? If it is, I'll create tests, documentation etc.

Just for the sake of completeness, here is the whole workflow to me:

1. A message routed to thekernel.terminate transport is dispatched.
2. TheSendMessageMiddleware gets the associated transport and send the message
3. KernelTerminateTransport::send() stores the message to be treated later.
4. If an exception occurs during the request, akernel.exception listener clears the spool of messages, so none are handled.
5. Onkernel.terminate,KernelTerminateTransport::flush() is executed,
   which callsKernelTerminateTransport::receive() with thecallable $handler(?Envelope $envelope) argument:
   • adding aReceivedMessage item to the envelope so the message is not sent again by theSendMessageMiddleware
   • dispatching it to the bus.
6. KernelTerminateTransport::receive() loops over stored messages and call$handler for each of them. Thus, each message is dispatched to be finally handled.

I'm just not sure about 4. Perhaps it should be configurable at the transport level as an option.

See#28646 (comment) for more thoughts on this.

I've updated the PR as per the comments (hope I understood all comments correctly...).
I'd like to ask for feedback on this issues:

1. I'd splitMemoryTransport into 2 classesMemoryTransport andSymfonyKernelEventTransport, the second one will containMemoryTransport plus the 2 kernel listener methods.
2. I also need to pass the bus to the memory transport but I'm not sure what's the best way to achieve it, it could be defined in the transport options, but then I'd need to inject it into the factory insrc/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php, the factory would then inject it in the memory transport. Any better way?

BTW does anyone have a sandbox project I could use to test this functionality?

@sroze@nicolas-grekas@ogizanagi Have updated the PR with suggestions given, it's not ready to review yet as it's not complete, but would like some feedback to check if I'm in the right direction before doing the final work.
Thanks!

@gonzalovilaseca : Sorry for the lack of answer.

I also need to pass the bus to the memory transport but I'm not sure what's the best way to achieve it

I think the factory should be aware of all the available buses, by injecting a service locator. Then, a transport option should allow the factory to select the right bus by its key.

@gonzalovilaseca : Sorry for the lack of answer.

I also need to pass the bus to the memory transport but I'm not sure what's the best way to achieve it

I think the factory should be aware of all the available buses, by injecting a service locator. Then, a transport option should allow the factory to select the right bus by its key.

Can you check what I've done insrc/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php? I've just defined an alias for the chosen bus, it would make sense to inject a service locator if the transport was able to use more than one, I think it's easier WDYT?

You may have more than one of such transport. For instance one per bus. The factory would be used to create each of these then (so it needs to know every buses).

updated!

@sroze@nicolas-grekas@ogizanagi Are we happy with this as it is, so I can start writing tests?

Updated!

@gonzalovilaseca: I hope you won't mind me, but I've rebased and pushed some changes to your branch hopefully fixing@sroze's review and some other tweaks I've spotted during this operation :)

@ogizanagi@sroze I've updated the PR with tests

@gonzalovilaseca : Great! :)

But I think we need to treat#28746 (comment). Consistency is the key, this transport dsn should work as an env var as any other.
The default recipe suggests aMESSENGER_TRANSPORT_DSN env var that one may use asMESSENGER_TRANSPORT_DSN=symfony://kernel.terminate.
This means the factory must register the event listener itself at runtime, not the extension.

Regarding#29097 (comment), I also think we should extract the re-dispatching logic out of theMemoryTransport, which would just keep messages in memory, no more. So thenull:// transport would just be a different factory.
But this last point could be done in a next PR, as we have time to iterate over this feature.

Can an event be registered at runtime? (I thought that wasnt possible as the container is already compiled)

Sure. You'll need to inject the@event_dispatcher in the factory, and useEventDispatcher::addListener.
The container being already compiled just means we won't see the tagged service definition usingdebug:container (nordebug:event-dispatcher unless the factory is called before).

Ok cool, will do that then.

@ogizanagi updated following suggestions

Any chance to get this merged into 4.3? (feature freeze is in two weeks)
How can I help?

It's just waiting for review..

Thank you very much for your efforts on this pull-request@gonzalovilaseca. Now that we have other transports (Doctrine especially) I think that the risks associated with such transport are too high:as mentioned by @fabpot ealier, running things onkernel.terminate are making things very hard to debug because you won't be able to see the errors (if some happen), even in development, nor be able to benefit from the retry mechanism that has been introduced.

Let's close this so we push everybody to use more reliable solutions 🚀

Sorry for making you work on this, but even if it wasn't merged, it helped a lot moving things forward! So thank you!