Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Messenger] Suggest to provide a DropMessageMiddleware #26901

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
ghost opened this issue Apr 12, 2018 · 5 comments
Closed

[Messenger] Suggest to provide a DropMessageMiddleware #26901

ghost opened this issue Apr 12, 2018 · 5 comments
Labels
Feature Messenger Status: Waiting feedback

Comments

@ghost
Copy link

ghost commented Apr 12, 2018

Q A
Bug report? no
Feature request? yes
BC Break report? no
RFC? no
Symfony version 4.1

Hi, in my project, I need to disable message dispatching for some edge-cases. For exemple, when loading data-fixtures, I need to disable mail delivery (welcome mails are sent on Doctrine persist event). For that, I use a processor with AliceFixture, and this processor enable or disable a middleware in charge of dropping the messages. Do you think that this middleware could be useful for someone else and should be embedded with the component?
@sroze sroze mentioned this issue Apr 13, 2018
Merged
@ogizanagi
Copy link
Contributor

ogizanagi commented Apr 14, 2018 •
edited
Loading

Hi @romain-pierre
What would you think about an ActivationMiddlewareDecorator that would allow to decorate any middleware (through DI service decoration) and define an activation/deactivation strategy? That would allow to disable a particular middleware in some environment while keeping the exact same middlewares stack between envs. Would it fit your need, or do you really need to drop the entire message handling? IIUC, you dispatch messages on Doctrine persist event?

@sroze
Copy link
Contributor

sroze commented Apr 30, 2018

👋 @romain-pierre. Did you see this question?

@ghost
Copy link
Author

ghost commented May 3, 2018

Both way seem valid to me, depending of the situation. The service decorator is probably the best way if we don't want to care about the middleware priority. Anyway it's always a simple option to write its own middleware to drop messages for edge cases.

@sroze
Copy link
Contributor

sroze commented May 8, 2018

Let's close it for now then :)

@sroze sroze closed this as completed May 8, 2018
@ogizanagi ogizanagi mentioned this issue May 20, 2018
Merged
@ogizanagi
Copy link
Contributor

I've opened #27320 btw

sroze added a commit that referenced this issue Jul 8, 2018
@sroze
feature #27320 [Messenger] Activation middleware decorator (ogizanagi)
b226859 
This PR was merged into the 4.2-dev branch.

Discussion
----------

[Messenger] Activation middleware decorator

| Q             | A
| ------------- | ---
| Branch?       | master <!-- see below -->
| Bug fix?      | no
| New feature?  | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | part of #26901   <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | TODO

A small middleware decorator that can be wired using DI decoration to enable/disable a middleware on an arbitrary condition. This can be used to keep the same middleware stack across env but enable/disable some of them through this.

Commits
-------

6e43838 [Messenger] Activation middleware decorator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature Messenger Status: Waiting feedback
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@sroze @xabbuh @ogizanagi