Skip to content

[Messenger] dispatch event when a message is retried #36152

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

Merged
merged 1 commit into from
Oct 2, 2020
Merged

[Messenger] dispatch event when a message is retried #36152

merged 1 commit into from
Oct 2, 2020

Conversation

nikophil
Copy link
Contributor

Q A
Branch? master
Bug fix? no
New feature? yes
Deprecations? no
License MIT

Hello,

i'm working on a bundle which helps to monitor messenger queues (add some stats for queues/transports + ability to manage failed messages from the browser)
https://github.com/SymfonyCasts/messenger-monitor-bundle/

and we're missing some hooks in the messaging system:

  1. a way to know when a message has been retried (fixed by dispatching a new WorkerMessageRetriedEvent in SendFailedMessageForRetryListener::onMessageFailed())
  2. a way to update the enveloppe in worker message events (fixed by adding AbstractWorkerMessageEvent::setEnvelope())

if needed i can provide some precise use cases.

thanks.

@chalasr
Copy link
Member

chalasr commented Mar 20, 2020

a way to update the enveloppe in worker message events (fixed by adding AbstractWorkerMessageEvent::setEnvelope())

Can you please provide a use case for this?

@chalasr chalasr added this to the next milestone Mar 20, 2020
@nikophil
Copy link
Contributor Author

nikophil commented Mar 21, 2020

@chalasr we're aggregating some metadata for each message (received_at, waiting_time, etc...)
thus, in order to track messages, we affect an id with a stamp once message is sent to transport leveraging SendMessageToTransportsEvent::setEnvelope().

But if a message is sent by another system (eg: in a micro-services architecture), we cannot use SendMessageToTransportsEvent and need another hook to add this id.

@chalasr
Copy link
Member

chalasr commented Mar 21, 2020

@nikophil Works for me, thanks.

Can you add a CHANGELOG entry for this?

Copy link
Contributor

@Tobion Tobion left a comment

Choose a reason for hiding this comment

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

-1 on this feature as people can just use the WorkerMessageFailedEvent with a priority that comes after the SendFailedMessageForRetryListener

@@ -29,6 +29,11 @@ public function getEnvelope(): Envelope
return $this->envelope;
}

public function setEnvelope(Envelope $envelope)
{
$this->envelope = $envelope;
Copy link
Contributor

@Tobion Tobion Mar 21, 2020

Choose a reason for hiding this comment

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

making the envelope mutable means, all the dispatching of events would need to be changed to refetch the potentially modified envelope, e.g. in

$event = new WorkerMessageReceivedEvent($envelope, $transportName);
$this->dispatchEvent($event);
if (!$event->shouldHandle()) {
return;
}
try {
$envelope = $this->bus->dispatch($envelope->with(new ReceivedStamp($transportName), new ConsumedByWorkerStamp()));

just adding a setter does not do anything by itself. -1 on doing this.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, this part is missing. But do you see it as a huge problem to (effectively) add $envelope = $event->getEnvelope()? I made the events immutable originally because I feel that it's always better to be conservative until we have a use-case. But this PR now does have a use-case.

Copy link
Contributor Author

@nikophil nikophil Mar 22, 2020

Choose a reason for hiding this comment

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

sorry i missed that...
in case this PR is accepted, i've fixed that and refetched envelope from mutable events.
i've added two new tests cases which check that events mutability is handled

Copy link
Member

Choose a reason for hiding this comment

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

Did we need to add this in the abstract class? This will affect (on master currently) 3 classes. Maybe we need hook points in all of them? But in this PR, we only need a hook point in one of them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, i'll do that, it will be less error prone this way

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done :)

@weaverryan
Copy link
Member

I'm still supportive of this feature, but we would need @Tobion to reconsider his vote :)

@fabpot
Copy link
Member

fabpot commented Aug 17, 2020

@Tobion Can you have another look at this PR?

@fabpot
Copy link
Member

fabpot commented Sep 6, 2020

@nikophil Still willing to finish this PR?

@nikophil
Copy link
Contributor Author

nikophil commented Sep 6, 2020

Hi, yes sorry, i'll do that shortly

@nikophil
Copy link
Contributor Author

nikophil commented Oct 1, 2020

@fabpot @Tobion i've fixed the PR, sorry for the delay

Copy link
Member

@weaverryan weaverryan left a comment

Choose a reason for hiding this comment

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

This is ready - it duplicates some logic from #32904, as both PR's needed the same extension point.

@fabpot
Copy link
Member

fabpot commented Oct 2, 2020

Thank you @nikophil.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants