Reporter is not starting since 1.5.1 for worker processes

[kwent]

Hi,

This PR is preventing the reporter to start in all our worker processes (sidekiq specifically).

Reversing to 1.5.0 fixes the issue on our side.

Regards

[jon-sully]

Hey @kwent, thanks for the report! Could you share with us what command you use for starting those Sidekiq processes?

[kwent]

Procfile

release: bin/migrate
web: bundle exec puma
worker: IS_SCHEDULER=true bundle exec sidekiq -t 20 -C config/sidekiq.yml

[adamlogic]

@kwent That PR suppresses the reporter when running in a Rake task or Rails console, and that shouldn't be the case when running bundle exec sidekiq.

Would you mind installing 1.5.1 (or 1.5.2, shouldn't matter) locally so we could see the output of the following statements? Paste them into an initializer (any initializer) and start Sidekiq via bundle exec sidekiq or by running the worker process from your Procfile.

puts "=" * 80
puts "console: #{defined?(::Rails::Console)}"
puts "rake: #{defined?(::Rake)}"
puts "rake app: #{defined?(::Rake) && Rake.respond_to?(:application)}"
puts "tasks: #{defined?(::Rake) && Rake.respond_to?(:application) && Rake.application.top_level_tasks.inspect}"
puts "=" * 80

[kwent]

Weirdly this is outputting same values.

using 1.5.0

================================================================================
console: constant
rake: constant
rake app: true
tasks: []
================================================================================

using 1.5.2

================================================================================
console: constant
rake: constant
rake app: true
tasks: []
================================================================================

[adamlogic]

Weirdly this is outputting same values

Oh right, that makes sense. v1.5.1 is the first version we started looking at those values to suppress the reporter, but the values would be the same regardless of our gem.

Thanks for doing this! It's really helpful, and I should have a fix out later today.

[adamlogic]

Nope, I take that back. I thought we were treating the empty array of rake tasks as truthy, but we're already calling .any? on it.

Can you run one more thing for me? Doesn't matter what version of the gem.

puts "=" * 80
puts "generate: #{defined?(::Rails::Command::GenerateCommand)}"
puts "=" * 80

[kwent]

Sure thing

================================================================================
generate:
================================================================================

[adamlogic]

Thanks, that's what I would expect, so I'm still baffled why the reporter would have been suppressed.

Do you have access to your application logs from when 1.5.1 was preventing the reporter from starting? I'd love to see the Judoscale logs (prefixed with [Judoscale]) from when your worker dyno booted.

[kwent]

Unfortunately way too hard for me to find this information ( we have lot of logs ).

[adamlogic]

Yep, I understand.

I've confirmed that we have several customers using v1.5.2 with Sidekiq processes reporting as expected, so the issue appears to be specific to your app.

If you decide to try the upgrade again and are able to capture those logs, please report back.

[kwent]

We were indeed using safer_rails_console Cf. #192. We upgraded to latest judoscale version and don't see this issue anymore. 🙏🏻