Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Messenger] Fix forced bus name gone after an error in delayed message handling#51468

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

@valtzu
Copy link
Contributor

@valtzuvaltzu commentedAug 23, 2023
edited
Loading

QA
Branch?6.3
Bug fix?yes
New feature?no
Deprecations?no
LicenseMIT

When consuming messages from an external source which do not have metadata/headers like bus name, you have to force the bus name with--bus in themessenger:consume command. However, if in the message handler you dispatch another message withDispatchAfterCurrentBusStamp, which then fails, end result is that the original message from external source is retried, but that forced bus name (BusNameStamp) is lost – so it will be retried on default bus instead. This isn't intended behavior, is it?


Not sure if changingDelayedMessageHandlingException::__construct signature is considered a BC break, it is not marked as internal so I am a bit worried 🤔

olesia-an reacted with thumbs up emoji
@carsonbotcarsonbot added this to the6.3 milestoneAug 23, 2023
@valtzuvaltzuforce-pushed thefix-missing-stamps-after-delayed-fail branch 2 times, most recently from5080561 to9f2ff70CompareAugust 24, 2023 18:23
@valtzu
Copy link
ContributorAuthor

valtzu commentedAug 24, 2023
edited
Loading

Added a test case to demonstrate the issue.


I wonder ifHandledStamp should still be dropped 🤔

@valtzuvaltzuforce-pushed thefix-missing-stamps-after-delayed-fail branch from9f2ff70 to2f04a64CompareAugust 24, 2023 18:35
@nicolas-grekas
Copy link
Member

Thank you@valtzu.

@nicolas-grekasnicolas-grekas merged commitb9be69f intosymfony:6.3Sep 29, 2023
@fabpotfabpot mentioned this pull requestSep 30, 2023
@jakubtobiasz
Copy link

@nicolas-grekas shouldn't it be this way?

    public function __construct(array $exceptions, ?Envelope $envelope = null)    {if (null === $envelope) {            trigger_deprecation(/* ... */);        }// ...    }

Currently it seems like a BC for me. I know it's a bug, but it can be fixed in a backward compatible way.

valtzu reacted with thumbs up emoji

GSadee added a commit to Sylius/Sylius that referenced this pull requestOct 4, 2023
…akubtobiasz)This PR was merged into the 1.13 branch.Discussion----------| Q               | A                                                            ||-----------------|--------------------------------------------------------------|| Branch?         | 1.12| Bug fix?        | no| New feature?    | no| BC breaks?      | no| Deprecations?   | no| Related tickets | n/a| License         | MITref:symfony/symfony#51468Commits-------b724783 Fix failing phpspec scenario on Symfony 6.3.5 and above
GSadee added a commit to Sylius/SyliusApiBundle that referenced this pull requestOct 4, 2023
…akubtobiasz)This PR was merged into the 1.13 branch.Discussion----------| Q               | A                                                            ||-----------------|--------------------------------------------------------------|| Branch?         | 1.12| Bug fix?        | no| New feature?    | no| BC breaks?      | no| Deprecations?   | no| Related tickets | n/a| License         | MITref:symfony/symfony#51468Commits-------b724783ab2e57b5ee3b04702473e917dc5fa4bad Fix failing phpspec scenario on Symfony 6.3.5 and above
nicolas-grekas added a commit that referenced this pull requestOct 25, 2023
…ackwards compatibility (xabbuh)This PR was merged into the 6.3 branch.Discussion----------[Messenger] declare constructor argument as optional for backwards compatibility| Q             | A| ------------- | ---| Branch?       | 6.3| Bug fix?      | yes| New feature?  | no| Deprecations? | no| Issues        |Fix#51468 (comment)| License       | MITCommits-------3810053 declare constructor argument as optional for backwards compatibility
fabpot added a commit that referenced this pull requestMay 7, 2024
…s (valtzu)This PR was squashed before being merged into the 6.4 branch.Discussion----------[Messenger] Don't drop stamps when message validation fails| Q             | A| ------------- | ---| Branch?       | 6.4| Bug fix?      | yes| New feature?  | no| Deprecations? | no| License       | MIT`ValidationMiddleware` has the same issue as `DispatchAfterCurrentBusMiddleware` did before the [fix](#51468): if message validation fails, stamps added by previous middlewares in the stack are dropped. What this means in practice is:1. `bin/console messenger:consume --bus=external` receives a message and `AddBusNameStampMiddleware` adds the `BusNameStamp` so that in case of failure it would be routed to a correct bus2. The message fails validation – the original envelope without the added `BusNameStamp` is sent to failure queue3. When running `bin/console messenger:failed:retry`, the message is dispatched on wrong bus (the default one)This has really bad implications if you handle the message differently depending on which bus it is received.Some refactoring was done to reduce duplication, similar to `WrappedExceptionsTrait`/`WrappedExceptionsInterface`.Commits-------fed32dc [Messenger] Don't drop stamps when message validation fails
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Projects

None yet

Milestone

6.3

Development

Successfully merging this pull request may close these issues.

4 participants

@valtzu@nicolas-grekas@jakubtobiasz@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp