danmayer / coverband

Ruby production code coverage collection and reporting (line of code usage)
https://github.com/danmayer/coverband
MIT License
2.46k stars 157 forks source link

Using COVERBAND_DISABLE_AUTO_START produces logging that Coverband failed to connect #529

Closed richkettle closed 4 months ago

richkettle commented 5 months ago

Hi

Thanks for this gem its going to save us an incredible amount of time in what we are trying to accomplish on our platform.

I have a query around COVERBAND_DISABLE_AUTO_START and Coverband trying to connect to Redis. We use another env var called COVERBAND_REDIS to specify the Redis url to connect to. Though that is not present in this configuration.

I have many many environments. Most of which I don't want coverband enabled on. We are using COVERBAND_DISABLE_AUTO_START="true" to disable it. However i'm seeing many logs:

coverage failed to store
Coverband Error: #<Redis::CannotConnectError: Error connecting to Redis on 127.0.0.1:6379 (Errno::ECONNREFUSED)> Error connecting to Redis on 127.0.0.1:6379 (Errno::ECONNREFUSED)

The environment continues to work as expected so its not causing any issues. It looks like its trying to connect to a default local redis process. We don't run Redis in the same environment.

The log appears to be Coverband attempting to do its eager loading, but I'm not sure if this means its trying to track something in an environment where it shouldn't be tracking. As mentioned earlier we don't supply the COVERBAND_REDIS var. Which is potentially why we are seeing these logs.

Another environment where we have just the COVERBAND_REDIS var set. But we also disable coverband. Doesn't seem to have these issues. Other environments where COVERBAND_REDIS is set also doesn't get these logs.

Coverband configuration:

.env

# Coverband settings (comment out COVERBAND_DISABLE_AUTO_START to enable)
COVERBAND_DISABLE_AUTO_START="true"
COVERBAND_REDIS="a_redis_url"

config/coverband.rb

# config/coverband.rb NOT in the initializers
Coverband.configure do |config|
  config.store = Coverband::Adapters::RedisStore.new(Redis.new(url: ENV["COVERBAND_REDIS"]))
  config.logger = Rails.logger

  # config options false, true. (defaults to false)
  # true and debug can give helpful and interesting code usage information
  # and is safe to use if one is investigating issues in production, but it will slightly
  # hit perf.
  config.verbose = false

  # default false. button at the top of the web interface which clears all data
  config.web_enable_clear = false

  # default false. Experimental support for tracking view layer tracking.
  # Does not track line-level usage, only indicates if an entire file
  # is used or not.
  config.track_views = false

  # default false. Experimental support for routes usage tracking.
  config.track_routes = false
end

Versions: We're using Rails 3 which doesn't seem to officially be supported by the latest version of the gem. But all seems good from the testing we've done. Coverband: 6.0.1

So my questions are:

Should I be getting these coverage failed logs with coverband disabled and no redis url set?

Is something tracking in the environments where coverband is disabled but the redis url is set?

danmayer commented 4 months ago

ok, I likely broke this in a refactoring around eager loading and I can try to take a look at fixing it.

richkettle commented 4 months ago

ok, I likely broke this in a refactoring around eager loading and I can try to take a look at fixing it.

Thank you!

danmayer commented 4 months ago

hmm so I can't reproduce this on main, nor can I reproduce it on Coverband 6.0.1 are you sure that ENV var is present at the bootup?

If you are using .env or Rails dot env as a gem to load your ENV vars, dotenv I am guessing it is not loading the ENV vars early enough for coverband to pick up on them during the preloading eager loading coverage phase. This can be solved by forcing that gem to load immediately and placing it before coverband in your gemfile.

gem 'dotenv-rails', require: 'dotenv/load' see this part of the readme https://github.com/danmayer/coverband?tab=readme-ov-file#working-with-environment-variables

danmayer@dellstation:~/projects/coverband_rails_example$ COVERBAND_REDIS=127.0.0.1:6379 bundle exec rails s
=> Booting Puma
=> Rails 7.1.3.2 application starting in development
=> Run `bin/rails server --help` for more startup options
E, [2024-04-20T14:42:29.956729 #99192] ERROR -- : coverage failed to store
E, [2024-04-20T14:42:29.956781 #99192] ERROR -- : Coverband Error: #<Redis::CannotConnectError: Connection refused - connect(2) for 127.0.0.1:6379> Connection refused - connect(2) for 127.0.0.1:6379
Puma starting in single mode...
* Puma version: 6.4.2 (ruby 3.2.2-p53) ("The Eagle of Durango")
*  Min threads: 1
*  Max threads: 1
*  Environment: development
*          PID: 99192
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop
^[[A^C- Gracefully stopping, waiting for requests to finish
=== puma shutdown: 2024-04-20 14:42:56 -0600 ===
- Goodbye!
Exiting
E, [2024-04-20T14:42:57.028417 #99192] ERROR -- : coverage failed to store
E, [2024-04-20T14:42:57.028464 #99192] ERROR -- : Coverband Error: #<Redis::CannotConnectError: Connection refused - connect(2) for 127.0.0.1:6379> Connection refused - connect(2) for 127.0.0.1:6379
E, [2024-04-20T14:42:57.028685 #99192] ERROR -- : Coverband: Coverband::Collectors::ViewTracker failed to store, error Redis::CannotConnectError info Connection refused - connect(2) for 127.0.0.1:6379
danmayer@dellstation:~/projects/coverband_rails_example$ COVERBAND_REDIS=127.0.0.1:6379 COVERBAND_DISABLE_AUTO_START=true bundle exec rails s
=> Booting Puma
=> Rails 7.1.3.2 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 6.4.2 (ruby 3.2.2-p53) ("The Eagle of Durango")
*  Min threads: 1
*  Max threads: 1
*  Environment: development
*          PID: 99522
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop
^C- Gracefully stopping, waiting for requests to finish
=== puma shutdown: 2024-04-20 14:43:10 -0600 ===
- Goodbye!
Exiting

So I don't think there is any bug related to this at the moment.

danmayer commented 4 months ago

Let me know if you have other issues closing this.