Skip to content

[Messenger] Add EventListener to handle delayed Messages on kernel.terminate event #50075

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

[Messenger] Add EventListener to handle delayed Messages on kernel.terminate event #50075

wants to merge 1 commit into from

Conversation

Koc
Copy link
Contributor

@Koc Koc commented Apr 20, 2023 •
edited
Loading

Q A
Branch? 6.3
Bug fix? no
New feature? yes
Deprecations? no
Tickets -
License MIT
Doc PR TBD

This PR adds possibility to register special "delayed" in-memory transport to delay messages handling on kernel.terminate event. It can be useful for non-critical but time-consuming operations like sending some analytics, metrics, various experiments like Parallel running, etc.

🔧 Usage:

# config/messenger.yaml
framework:
    messenger:
        delayed_transport: delayed
        transports:
            delayed: 'in-memory://'
        routing:
            'App\Presentation\Message\TrackSearchAnalyticsMessage': delayed
final class SearchProductsController
{
    public function __construct(MessageBusInterface $commandBus)
    {
    }

    #[Route('/api/public/v1/products', name: 'search_products', methods: 'GET')]
    public function __invoke(#[MapQueryParameter] string $query): ProductsCollectionResponse
    {
        // do search ...

        // message will be handled on "kernel.terminate" instead of immediate handling
        $this->commandBus->dispatch(new TrackSearchAnalyticsMessage($query));

        return $response;
    }
}

🗒️ Todo:

  • Changelog
  • tests

@carsonbot carsonbot added this to the 6.3 milestone Apr 20, 2023
@Koc Koc force-pushed the feature/delayed-messenger-transport branch from 0add76d to 12d0402 Compare April 24, 2023 21:58
@nicolas-grekas nicolas-grekas modified the milestones: 6.3, 6.4 May 23, 2023
@nicolas-grekas nicolas-grekas modified the milestones: 6.4, 7.1 Nov 15, 2023
@magikid
Copy link
Contributor

magikid commented Dec 3, 2023

If you have a time consuming task, why are you running the handler during the request instead of in a separate process?

@Koc
Copy link
Contributor Author

Koc commented Dec 4, 2023

@magikid

It can be useful for non-critical but time-consuming operations like sending some analytics, metrics, various experiments like Parallel running, etc.

Adding separate consumers for some simple tasks can increase complexity of the infrastructure.

artyuum
artyuum reviewed Dec 5, 2023
View reviewed changes
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
@@ -1519,6 +1519,10 @@ function ($a) {
->defaultNull()
->info('Transport name to send failed messages to (after all retries have failed).')
->end()
->scalarNode('delayed_transport')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the naming confusing. To me, it sounds like my message could be delayed no matter the transport used (like this) while this option actually brings a different strategy of handling the message: using the kernel.terminate event.

Maybe handle_after_request would be more suitable?

@valtzu
Copy link
Contributor

valtzu commented Dec 5, 2023 •
edited
Loading

How about using stamp+middleware, similar to DispatchAfterCurrentBusStamp? Instead of running a Worker on kernel.terminate, we would just finish the middleware stack execution 🤔 This would support any transport.

Also this would make it easy to ignore the "delaying" behavior when running on CLI.

@xabbuh xabbuh modified the milestones: 7.1, 7.2 May 15, 2024
@fabpot fabpot modified the milestones: 7.2, 7.3 Nov 20, 2024
@chalasr
Copy link
Member

chalasr commented Mar 29, 2025

Closing as there is no more activity here. Please feel free to reopen

@OskarStark OskarStark closed this Mar 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@94noni 94noni 94noni left review comments

@artyuum artyuum artyuum left review comments

Assignees
No one assigned
Labels
Feature Messenger Status: Needs Review
Projects
None yet
Milestone
7.3
Development

Successfully merging this pull request may close these issues.