resque-pool defaulting to test environment

[ConorNugent]

I set up resque-pool locally today and I have noticed some strange behaviour. I had previously got plain old resque up and running no problem. My jobs were failing because records could not be found. When I dug into this I found that this is because the workers are being set up with the test configuration. I'm using foreman/heroku local and my .env file sets the environmentRACK_ENV=development, I also tried added a RACK_ENV=development

Sample set up output

[OKAY] Loaded ENV .env File as KEY=VALUE Format
5:01:34 PM web.1    |  Puma starting in single mode...
5:01:34 PM web.1    |  * Version 3.6.0 (ruby 2.3.0-p0), codename: Sleepy Sunday Serenity
5:01:34 PM web.1    |  * Min threads: 5, max threads: 5
5:01:34 PM web.1    |  * Environment: development
5:01:34 PM worker.1 |  resque-pool-manager[curio-api][1751]: Resque Pool running in development environment
5:01:36 PM web.1    |  * Listening on tcp://0.0.0.0:3000
5:01:36 PM web.1    |  Use Ctrl-C to stop
5:01:36 PM worker.1 |  resque-pool-manager[curio-api][1751]: started manager

My tasks/resque.rake file

require 'resque/pool/tasks'

# this task will get called before resque:pool:setup
# and preload the rails environment in the pool manager
task "resque:setup" => :environment do
  # generic worker setup, e.g. Hoptoad for failed jobs
end

task "resque:pool:setup" => :environment do
  # close any sockets or files in pool manager
  ActiveRecord::Base.connection.disconnect!
  # and re-open them in the resque worker parent
  Resque::Pool.after_prefork do |job|
    ActiveRecord::Base.establish_connection
  end
end

I'm not sure why the environment variables aren't being picked. I'm also a little surprised that resque-pool is defaulting to test. I'm using 0.6.0 in a rails 5.0 api only app. I'm sure I must be doing something silly but I can't see what it it

Just in case it helps, messing around with byebug

✗ resque-pool

[7, 16] in /Users/conornugent/Dev/neighbourwood/curio/curio-api/lib/tasks/resque.rake
    7: end
    8:
    9: task "resque:pool:setup" => :environment do
   10:   # close any sockets or files in pool manager
   11:   byebug
=> 12:   ActiveRecord::Base.connection.disconnect!
   13:   # and re-open them in the resque worker parent
   14:   Resque::Pool.after_prefork do |job|
   15:     ActiveRecord::Base.establish_connection
   16:   end
(byebug) Rails.env
"test"
(byebug) ActiveRecord::Base.connection.current_database
"curio-api_test"

[ConorNugent]

I ended up changing my Procfile to

worker: bundle exec rake resque:pool

and the environment was picked up correctly. Any idea why there is a difference in behaviour?

[brucek]

I'm just seeing this too. It turns out that resque-pool invokes Rake.application["resque:pool"].invoke (via lib/resque/pool/cli.rb)

For some reason, this does not set Rake.application.top_level_tasks, so that is set to ["default"].

Unfortunately, Rails 4.2.7.1 sets ENV['RAILS_ENV'] ||= 'test' (in railties/lib/rails/test_unit/railtie.rb) when any of the Rake.application.top_level_tasks is "default", which you are probably loading in config/application.rb

[...]

OK so it looks like Rake.application.init is the culprit. I have a fix in #160

[robinmonjo]

Thank you for the PR @brucek hopefully this will be merged some days :). I had the same problem today, however, couldn't switch to bundle exec rake resque:pool as suggested since this doesn't consider the TERM_CHILD env while resque-pool does (see: #150).

So I ended up doing:

namespace :pool do
    task :setup => :environment do
      if Rails.env == "test" # default env will be "test" if no RAILS_ENV / RAKE_ENV config are set
        puts "Please set RAILS_ENV=development"
        exit(1)
      end
      Resque::Pool.after_prefork do |job|
        Resque.redis.client.reconnect
      end
    end
  end

to force dev users to set the RAILS_ENV