I think this does not yet belong to Symfony EventDispatcher:
the queue-interop dependency is not stable (in the sense that it's not yet widely reviewed nor implemented nor used.)
the implementation is totally independent from the current code, which means the code can be released as a standalone library, isn't it?
I'd suggest to do so, and keep up the work on a queue-interop goal for sure!

I beleive @lyrixx is against the proposal as it has a competing implementation in the works.

If this accepted I don't believe it should be part of the EventDispatcher but has it's own Component.

The EventDispatcher Symfony uses is based on the Mediator pattern, where the event can be modified after being dispatched, the Async may not work as one currently excepts from EventDispatcher. In fact, the name EventDispatcher might be wrongfully used for this component 😄

I would very like such a feature in the core, but have the same opinion as @sstok that it shouldnt be mixed up with the current event dispatcher, but instead should be its own component with specifically optimized interfaces for this purpose.

what is the status of this feature ?

Thank you for this PR.

I agree with Nicholas. The event dispatcher component should not be used for async messages like this. When using async messages you want events to be broadcasted and immutable. That are two fundamental features the event dispatcher does not support by design.

I was down this route a few year ago with https://github.com/fervo/deferred-event-worker

I suggest this PR to be closed.

hi.

Thanks for this PR. I also agree with @Nyholm and @nicolas-grekas

We may re-open it later when a nice support of async will land in Symfony. For now, It's a bit too early IMHO.

I suggest this PR to be closed.

Let's close this because of the downvotes from the Core Team members .. but we can reconsider it in the future. Thanks!

With the new messaging component #24411 , you'll be able to defer the execution of events.