Open gczh opened 1 month ago
Huh, no, this is very strange. Mission Control doesn't do anything with DB connections, it relies solely on Solid Queue's connections, so it uses whatever Solid Queue is using. I haven't seen anything like this before. Are you manually configuring Mission Control's applications or relying on the default configuration?
Huh, no, this is very strange. Mission Control doesn't do anything with DB connections, it relies solely on Solid Queue's connections, so it uses whatever Solid Queue is using. I haven't seen anything like this before. Are you manually configuring Mission Control's applications or relying on the default configuration?
Ahhh, gotcha! This is what it looks like for me in development.rb
config.active_job.queue_adapter = :solid_queue
config.solid_queue.connects_to = { database: { writing: :queue, reading: :queue } }
config.solid_queue.logger = ActiveSupport::Logger.new(STDOUT, level: :debug)
config.log_level = :debug
I'm trying to figure out if there is any way to determine the database that MissionControl is connected to. At the moment, what seems to be the case is this:
When running
SolidQueue::Job.connection.raw_connection
inrails console
, it seems to be using the local database configured indatabase.yml
However, when I look at
website.com/jobs
andlocalhost:3000/jobs
, it seems that the number of jobs completed is exactly the same. This leads me to believe that the MissionControl on localhost is actually pointing to theQUEUE_DATABASE_URL
indatabase.yml
However, even after commenting out that in
.env
, it still seems to be connecting to the remote queue database.Other notes
Looks like if I were to comment out the queue database configuration for
production
indatabase.yml
, MissionControl would then point to development's database correctly.I undid the comments after restarting the server, and it's still pointing to the local db, which is the correct and expected behaviour. This makes me wonder if MissionControl is caching database connections somehow?