-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] Add WorkerMetadata
to Worker
class.
#42335
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
Conversation
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
c267c7c
to
25902aa
Compare
Hey! I think @alexander-schranz has recently worked with this code. Maybe they can help review this? Cheers! Carsonbot |
WorkerMetadata
to worker lifecycle events
@carsonbot find another a reviewer please. |
@tienvx could maybe review this PR? |
Friendly ping @Nyholm. |
Hi 👋🏻 I may ask a strange question but what's the benefits compared to using a As an event already receive the |
Hi, indeed, the whole PR might be replaced with one or a couple getters but:
|
I like the idea of using an object but I think it's fine to make it accessible from the Worker instead of passing it to all worker-aware events. |
WorkerMetadata
to worker lifecycle eventsWorkerMetadata
to Worker
class.
3c10761
to
afeaf60
Compare
@chalasr I've refactored the PR according to your suggestions. Should be good to go once the CI is green. |
53caaa0
to
20b3222
Compare
20b3222
to
9260aa6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks cool.
But one question:
from where you gonna call $worker->getWorkerMetadata()
?
Much thanks for the review @lyrixx, appreciate it! |
Add tests for WorkerMetadata class Fix WorkerMetadataTest header Access WorkerMetadata directly via getter and make it mutable. Fix CS Refactor WorkerMetadata::set() method to accept array Use null as default value for queueNames instead of false Add missing return type Make fabbot happy
ff7520c
to
583f85b
Compare
Rebased, squashed & updated the PR description. Should be good to go now 🥳 . |
Thanks for your work on this new feature! |
At the moment, there is no clean way to access the values of
transportNames
or recently introducedqueueNames
that the worker was configured with, although such data might be quite useful for logging/monitoring or other tasks.This PR attempts to fix that by adding a new and extensible way to provide additional information about a particular
Worker
object.So far, the following PRs could benefit from this change:
SIGTERM
is received #42723Use case example:
async
.idle
.Before this PR, the only solution not relying on using Reflection API would look like this:
With this PR, one could simply use this to retrieve the transport name.
So the whole solution would look like this: