You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
I use a new feature added in #41163 with UidProcessor from Monolog. Recently I've realized the last INFO log from the messenger ("{class} was handled successfully (acknowledging to transport)") has a uid from the following message in a queue. It happens because that log message writes after the WorkerMessageHandledEvent that triggers resetting. It sounds silly, but I've spent hours trying to understand why a wrong message has a positive acknowledgment.
19:50:03 INFO [messenger] Received message App\Message ["class" => "App\Message"] ["uid" => "4f9fa66"]
19:50:03 INFO [messenger] Message App\Message handled by App\Handler::__invoke ["class" => "App\Message","handler" => "App\Handler::__invoke"] ["uid" => "4f9fa66"]
19:50:03 INFO [messenger] App\Message was handled successfully (acknowledging to transport). ["class" => "App\Message"] ["uid" => "17280ae"]
19:50:04 INFO [messenger] Received message App\Message ["class" => "App\Message"] ["uid" => "17280ae"]
19:50:04 INFO [messenger] Message App\Message handled by App\Handler::__invoke ["class" => "App\Message","handler" => "App\Handler::__invoke"] ["uid" => "17280ae"]
19:50:04 INFO [messenger] App\Message was handled successfully (acknowledging to transport). ["class" => "App\Message"] ["uid" => "b3d9ee5"]
Possible Solution
I think the service resetting should be the last thing in a handling loop: after logging, after acknowledging. The actual event for that is WorkerRunningEvent. The event doesn't have a transport name, but it's trivial to fix. Nevertheless, I have doubts about all of this.
The text was updated successfully, but these errors were encountered:
…ledging (upyx)
This PR was merged into the 5.4 branch.
Discussion
----------
[Messenger] Move container resetting after receiver acknowledging
| Q | A
| ------------- | ---
| Branch? | 5.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#43114
| License | MIT
| Doc PR | nope
It fixes the #43114 issue and similar potential bugs. The `ResetServicesListener` lean on events sequence: the `AbstractWorkerMessageEvent` to save the actual receiver name, then the `WorkerRunningEvent` to check that name and reset the container. It may look fragile, so let's discuss it in the issue.
Commits
-------
fc85aef [Messenger] Move container resetting after receiver acknowledging (in command)
Symfony version(s) affected: 5.4.x
Description
I use a new feature added in #41163 with
UidProcessor
from Monolog. Recently I've realized the last INFO log from the messenger ("{class} was handled successfully (acknowledging to transport)") has a uid from the following message in a queue. It happens because that log message writes after theWorkerMessageHandledEvent
that triggers resetting. It sounds silly, but I've spent hours trying to understand why a wrong message has a positive acknowledgment.How to reproduce
Register service:
Configure messenger:
Consume some message:
Example output:
Possible Solution
I think the service resetting should be the last thing in a handling loop: after logging, after acknowledging. The actual event for that is
WorkerRunningEvent
. The event doesn't have a transport name, but it's trivial to fix. Nevertheless, I have doubts about all of this.The text was updated successfully, but these errors were encountered: