Skip to content

Auto-detect SolidQueue #254

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

karlentwistle
Copy link

@karlentwistle karlentwistle commented Nov 30, 2024

Issue

#237

Description of changes

Adds SolidQueue as an auto-detected framework.

Reading through the Solid Queue docs it says:

Solid Queue's supervisor will fork a separate process for each supervised worker/dispatcher/scheduler.

~ https://github.com/rails/solid_queue?tab=readme-ov-file#workers-dispatchers-and-scheduler

It also offers four hooks

SolidQueue.on_start
SolidQueue.on_stop

SolidQueue.on_worker_start
SolidQueue.on_worker_stop

~ https://github.com/rails/solid_queue?tab=readme-ov-file#lifecycle-hooks

So I found that by adding

# config/initializers/solid_queue.rb

SolidQueue.on_worker_start do
  # Re-open appenders after forking the process
  SemanticLogger.reopen
end

The logs started to appear in STDOUT.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Adds SolidQueue as an auto detected framework
@MiroslavCsonka
Copy link

Thanks for opening this! It solved our week-long issue on Heroku. I can stop spamming their support. I hope it will get merged soon for others to save a bunch of time.

@hms
Copy link

hms commented Feb 6, 2025

@karlentwistle @MiroslavCsonka

The latest releases of SolidQueue have an #on_start for the dispatcher and scheduler. This PR needs to add a SemanticLogger.reopen for the 2 new on_start blocks.

Also, if interesting, I'm doing this in my #on_start blocks:
Rails.logger.name = "#{Rails.application.name}::Supervisor"
Rails.logger.name = "#{Rails.application.name}::Worker"
...
...

@karlentwistle
Copy link
Author

karlentwistle commented Jun 13, 2025

@hms Thanks, and sorry for the delay! I've updated the PR based on your comment.

I didn’t include the following lines:

Rails.logger.name = "#{Rails.application.name}::Supervisor"
Rails.logger.name = "#{Rails.application.name}::Worker"

Since I didn’t see any existing precedent for this in lib/rails_semantic_logger/engine.rb. That said, it’s useful to know about, and I’ll add it to my own app via an initializer.

If a maintainer could let me know if you'd like me to include it in this PR, I can add it. It seems like a sensible default to me.

@karlentwistle karlentwistle force-pushed the ke/auto_detect_solid_queue branch from a0d7377 to 0e03187 Compare June 13, 2025 09:11
@hms
Copy link

hms commented Jun 14, 2025

@karlentwistle

Since your PR and my comment, solid_queue now has on_start blocks for the supervisor and scheduler. I believe you need to update the PR to add a reopen there too.

hms

@karlentwistle
Copy link
Author

karlentwistle commented Jun 14, 2025

@hms I saw you got rails/solid_queue#486 merged - nice! Do you mean something beyond

# Re-open appenders after SolidQueue worker/dispatcher/scheduler has finished booting
SolidQueue.on_worker_start { ::SemanticLogger.reopen } if defined?(SolidQueue.on_worker_start)
SolidQueue.on_dispatcher_start { ::SemanticLogger.reopen } if defined?(SolidQueue.on_dispatcher_start)
SolidQueue.on_scheduler_start { ::SemanticLogger.reopen } if defined?(SolidQueue.on_scheduler_start)

It seems like the supervisor would be

SolidQueue.on_start { ::SemanticLogger.reopen } if defined?(SolidQueue.on_start)

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