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

Skip to content

[Mailer] 6.2 dev - MessageEvent listener not called #47989

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
silverbackdan opened this issue Oct 25, 2022 · 13 comments · Fixed by #47992
Closed

[Mailer] 6.2 dev - MessageEvent listener not called #47989

silverbackdan opened this issue Oct 25, 2022 · 13 comments · Fixed by #47992
Labels
Bug Mailer Status: Needs Review

Comments

@silverbackdan
Copy link

Symfony version(s) affected

6.2-dev

Description

Working fine on current 6.2 branch.

I define an event listener like this:

$services
        ->set(MessageEventListener::class)
        ->tag('kernel.event_listener', ['event' => MessageEvent::class])
        ->args(
            [
                '%env(MAILER_EMAIL)%',
            ]
        );

However the handler is no longer being called.

How to reproduce

I'm trying to work out why the AbstractTransport::send method does not appear to be called anymore and why the MessageEvent event listener would not be fired.

Possible Solution

No response

Additional Context

No response
@silverbackdan silverbackdan changed the title [Mailer] 6.2 dev - message event listener not fired [Mailer] 6.2 dev - MessageEvent listener not fired Oct 25, 2022
@silverbackdan silverbackdan changed the title [Mailer] 6.2 dev - MessageEvent listener not fired [Mailer] 6.2 dev - MessageEvent listener not called Oct 25, 2022
@chalasr
Copy link
Member

chalasr commented Oct 25, 2022 •
edited
Loading

Thanks for the report. I suspect this is due to #47191 changing the dispatched event name when extending MessageEvent. Could you confirm?

@silverbackdan
Copy link
Author

Previously this would work. But now in my tests the event that is fired is QueuingMessageEvent that I'd need to listen to in my case.
In my tests I am disabling the mailer DSN null://null
So in a real world scenario, this probably wouldn't be a break.
But during tests I think the transports are being skipped and therefore the event not fire to populate the from email header in my case which is what I'm testing is being populated.

@silverbackdan
Copy link
Author

I do think that's the case - previously I guess this event would have been called and should be ignored because it was a queued event. But it's better to have this separate I agree.
So now the event would only be fired if the transport is called, so during tests, there is no transport being called, and so my tests fail.

@silverbackdan
Copy link
Author

silverbackdan commented Oct 25, 2022 •
edited
Loading

Would you have any recommendation on how to ensure during tests, when I have disabled transports that I am testing for listening to the event properly? Is it worth in the component, when transport is disabled, still emitting that event?

Looking at the NullTransport, I'd have thought send should still be called though and the event emitted, so I'll do some more digging.

@chalasr
Copy link
Member

chalasr commented Oct 25, 2022

I do think this is a BC break we should fix. /cc @fabpot

@silverbackdan
Copy link
Author

Also to do with messenger being installed, even is I set to disable the bus. I'm working through to see what I can find though :)

framework:
    mailer:
        dsn: '%env(MAILER_DSN)%'
        message_bus: ~

@chalasr
Copy link
Member

chalasr commented Oct 25, 2022

No worry, thanks for testing the beta!
May I ask you to keep this one focus on the event name change and open another one (or more) with the information/code needed to reproduce?

@silverbackdan
Copy link
Author

Sure thing. I'll delete other comments here and open one for this other issue.

@chalasr chalasr mentioned this issue Oct 25, 2022
Merged
@chalasr
Copy link
Member

chalasr commented Oct 25, 2022

Should be fixed by #47992

@silverbackdan
Copy link
Author

Thanks, shame to revert the change but appreciate your fast response and fix time!

@silverbackdan
Copy link
Author

This was 1 of 3 issues found unfortunately, but happy to be running tests on the beta branches and able to give you all a heads up :)

@chalasr
Copy link
Member

chalasr commented Oct 25, 2022

Thanks, shame to revert the change but appreciate your fast response and fix time!

No big deal, the new feature keeps working despite reverting that part.

This was 1 of 3 issues found unfortunately, but happy to be running tests on the beta branches and able to give you all a heads up :)

Thanks to you!

@nesl247
Copy link

nesl247 commented Oct 25, 2022

This seems related to #47383.

@fabpot fabpot closed this as completed Oct 26, 2022
fabpot added a commit that referenced this issue Oct 26, 2022
@fabpot
bug #47992 [Mailer] Fix BC breaking event name change (chalasr)
3b4cda1 
This PR was merged into the 6.2 branch.

Discussion
----------

[Mailer] Fix BC breaking event name change

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #47989, Fix #47383
| License       | MIT
| Doc PR        | -

While I get the motivation for introducing this `QueuingMessageEvent` child event in #47191, it's a BC break that is difficult to circumvent due to the fact it's an event (the parent may still be used as it's not deprecated).
So I propose to revert its addition and just add the needed stamp-related methods to the original event instead.

Commits
-------

cb64938 [Mailer] Fix BC breaking event name change
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Mailer Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Mailer] Fix BC breaking event name change chalasr/symfony
5 participants
@fabpot @nesl247 @chalasr @carsonbot @silverbackdan