-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] Move RejectRedeliveredMessageMiddleware
to AMQP Package
#41749
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.
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
[Messenger] Move RejectRedeliveredMessageMiddleware
to AMQP Package
#41749
Conversation
Warxcell
commented
Jun 19, 2021
•
edited by nicolas-grekas
Loading
edited by nicolas-grekas
Q | A |
---|---|
Branch? | 5.4 |
Bug fix? | no |
New feature? | no |
Deprecations? | yes |
Tickets | Fix #41748 |
License | MIT |
Doc PR |
88b914e
to
e158c56
Compare
Can you show the stack trace of the error that you receive? I do not really see why the current code should trigger it. |
Sure, https://travis-ci.org/github/Warxcell/files/jobs/773978302#L785 If I do |
I think we should prevent the use of |
Why? To me it's looks like this middleware is tighly coupled to AMQP package, why not ship it inside it and load it only when installed, rather than ship it globally in Messenger, load it always, and check on every message if class exists? |
We can think about adding a new middleware in another namespace and deprecate the other one. But such a change must not happen in a patch release and would have to target the |
Ok, so I will redirect this to 5.4 and your fix will be patched in 5.2 ? |
c6a8671
to
2937f33
Compare
Please fix commit+PR title |
2937f33
to
533f5b7
Compare
533f5b7
to
e293f17
Compare
I'm working on an alternative AMQP transport for messenger based on bunny library. Moving this class will complicate dependency tree. Can we choose the way @xabbuh proposes to avoid that? EDIT: This class is indeed so tightly coupled to |
RejectRedeliveredMessageMiddleware
to AMQP Package
@Warxcell Looks good to me. Can you rebase on 6.2 and update the code accordingly? Thank you. |
On closer look, I think we should close this PR. The linked issue has been fixed, which means that in practice, this is change is just a nice to have. Yes, the implementation knows only about some amqp stamp at the moment, but we could also imagine a day where it manages other kind of stamps. |
Thanks for having a look Nicolas. Let's close then. |