Add a default logger in bin/jobs

[dennispaagman]

Hello,

I'm wondering if it's a good idea to add a default logger in the generated bin/jobs file. I use it in development and was expecting at least some log output from it, but it's entirely silent.

What works for me locally is adding:

SolidQueue.logger = ActiveSupport::Logger.new($stdout)

do you feel like adding this makes sense? I'll happily create a PR if so :)

I'm not sure if it's ok to rely on Active Support like this directly, so suggestions are also welcome.

[dennispaagman]

Hmm I just noticed if I define the logger like that, the related AR query logs still only end up in log/development.log 🤔

If I run it in puma plugin mode I do get them all together, but I guess that makes sense as they will share the same logger then.

[rosa]

Hey @djfpaagman! By default, Solid Queue uses Rails's logger, which in development writes to log/development.log, so that's where you'll find the logs from bin/jobs. If you initialize it to:

ActiveSupport::Logger.new($stdout)

the queries logged by Active Record would still go to the logger configured in ActiveRecord::Base.logger, which I think should be Rails.logger too, so log/development.log 🤔

[dennispaagman]

hi @rosa!

Indeed that's how it's happening right now, it's just not the expected behavior for me.

I run my app through foreman with a Procfile like so:

web: bin/rails s
vite: bin/vite dev
jobs: bin/jobs

By default, the logs from Solid Queue are not visible anywhere and only go to development.log.

If I run Solid Queue via the Puma plugin I do get all the logs in my web process (as they then share the rails logger?).

If I configure the logger explicitly I only get the logs from Solid Queue itself (the ones defined in https://github.com/rails/solid_queue/blob/main/lib/solid_queue/log_subscriber.rb), but not the AR logs.

I would expect all the logs from a particular process to be sent to the output of that process when configured to log there. And I think it would make sense to do that by default, at least in development environments.

[tannakartikey]

It would be good to see the logs on STDOUT along with Rails logs. I use Overmind and I don't see the logs. I do tail -f log/development.log in a separate terminal or in Procfile.

[zarqman]

Since SolidQueue uses the Rails logs, you may wish to change your development logs to just go to STDOUT all the time. I use foreman here, and just set this in my environments/development.rb:

# rails 8 version:
config.logger   = ActiveSupport::TaggedLogging.logger(STDOUT)

# or rails 7.x (and earlier):
config.logger = ActiveSupport::Logger.new(STDOUT)
  .then { |logger| ActiveSupport::TaggedLogging.new(logger) }

Both Rails and SolidQueue will then log into your foreman/overmind/whatever process, and no longer to disk.

If you really want logs to also go to log/development.rb, you can get fancy with BroadcastLogger (which, IIRC, arrived in Rails 7.1).

[janko]

I was also surprised when bin/jobs was entirely silent, I honestly thought it was hanging, that I didn't set something up correctly. Coming from Sidekiq, it would be reassuring to see a screen confirming the Solid Queue process has successfully booted, and also to see jobs being processed and low long they took. With the default settings, the only way I can confirm that a job was picked up and processed is in Mission Control.

[rosa]

This is a mix of several things:

• Solid Queue is not configured by default in development, or intended for development. There's the async adapter for that.
• Rails's logger in development writes to log/development.log
• People configure Solid Queue in development and don't change the default logger, which is Rails's logger (this is documented).
• Then they get surprised they don't see the logs in STDOUT, which is the expected behaviour because the logs are in log/development.log.

I get it, but this is just a consequence of using something in development that wasn't intended for development without understanding all the pieces involved. I'll get the instructions to run it in development improved (#390, plus I'll add a note about the logger).

[janko]

Yeah, that makes sense. I guess some people have it in development to test with the real thing, in our project we use Sidekiq in development.

Rails's logger in development writes to log/development.log

This part I don't understand fully. If that's true, then how come I see ActionController/ActiveRecord/ActiveJob/etc logs in the terminal in development, both in rails server and console? When I inspect Rails.logger in the console of a new Rails 8.0 app, I see it's an ActiveSupport::BroadcastLogger across development.log and STDERR.

If Solid Queue is using this same logger, then why don't I see its logs in the terminal as well? 🤔

[rosa]

then how come I see ActionController/ActiveRecord/ActiveJob/etc logs in the terminal in development

Because when you run rails server, you're running this command that logs to STDOUT in development. bin/jobs has nothing like that because it wasn't made with development in mind.