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

Appearance settings

[12.x] feat: Add WorkerStarting event when worker daemon starts #55941

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 7 commits into from
Jun 6, 2025

Conversation

Orrison
Copy link
Contributor

@Orrison Orrison commented Jun 6, 2025

Creates a new WorkerStarting event that fires just as a new worker daemon starts.

This provides an excellent hook point to perform actions just as a worker starts, instead of having to rely on handling things before processing individual jobs.
I have personally encountered the need to apply extra setup as a worker starts. Without this, I have needed to execute certain setup before each job starts with JobProcessing.

Although the core of the change is backward compatible, I added a starting method to src/Illuminate/Queue/QueueManager.php and the src/Illuminate/Contracts/Queue/Monitor.php interface. Which I can revert if it is determined that the changing of an interface is not wanted at this time.

Orrison added 3 commits June 5, 2025 21:12
Signed-off-by: Kevin Ullyott <ullyott.kevin@gmail.com>
Signed-off-by: Kevin Ullyott <ullyott.kevin@gmail.com>
Signed-off-by: Kevin Ullyott <ullyott.kevin@gmail.com>
@Orrison Orrison changed the title Add WorkerStarting event when worker daemon starts [12.x] feat: Add WorkerStarting event when worker daemon starts Jun 6, 2025
Orrison added 2 commits June 5, 2025 22:32
Signed-off-by: Kevin Ullyott <ullyott.kevin@gmail.com>
Signed-off-by: Kevin Ullyott <ullyott.kevin@gmail.com>
@rodrigopedra
Copy link
Contributor

Changes in interfaces should be sent to master.

For this PR, you can revert only the interface change, and then after approval send a PR to the master branch.

Currently, for a project, I listen to the Illuminate\Console\Events\CommandStarting event, as I need to decide which API key to provide from a pool of keys depending on the queue value being handled by a worker.

This change will simplify this logic by a lot. Thanks!

Signed-off-by: Kevin Ullyott <ullyott.kevin@gmail.com>
@Orrison
Copy link
Contributor Author

Orrison commented Jun 6, 2025

Changes in interfaces should be sent to master.

For this PR, you can revert only the interface change, and then after approval send a PR to the master branch.

Currently, for a project, I listen to the Illuminate\Console\Events\CommandStarting event, as I need to decide which API key to provide from a pool of keys depending on the queue value being handled by a worker.

This change will simplify this logic by a lot. Thanks!

Done

@taylorotwell taylorotwell merged commit 4bed165 into laravel:12.x Jun 6, 2025
59 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.