Run SolidQueue supervisor inside Puma in production
Production switched the queue adapter back to :solid_queue but the Puma plugin had been removed, so jobs (e.g. invitation resend) enqueued fine but never ran. Clinch ships as a single container, so always start the supervisor in production rather than gating on SOLID_QUEUE_IN_PUMA. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -38,10 +38,6 @@ env:
|
|||||||
secret:
|
secret:
|
||||||
- RAILS_MASTER_KEY
|
- RAILS_MASTER_KEY
|
||||||
clear:
|
clear:
|
||||||
# Run the Solid Queue Supervisor inside the web server's Puma process to do jobs.
|
|
||||||
# When you start using multiple servers, you should split out job processing to a dedicated machine.
|
|
||||||
SOLID_QUEUE_IN_PUMA: true
|
|
||||||
|
|
||||||
# Set number of processes dedicated to Solid Queue (default: 1)
|
# Set number of processes dedicated to Solid Queue (default: 1)
|
||||||
# JOB_CONCURRENCY: 3
|
# JOB_CONCURRENCY: 3
|
||||||
|
|
||||||
|
|||||||
@@ -34,7 +34,9 @@ port ENV.fetch("PORT", 3000)
|
|||||||
# Allow puma to be restarted by `bin/rails restart` command.
|
# Allow puma to be restarted by `bin/rails restart` command.
|
||||||
plugin :tmp_restart
|
plugin :tmp_restart
|
||||||
|
|
||||||
# Solid Queue plugin removed - now using async processor
|
# Run the Solid Queue supervisor inside Puma. Clinch ships as a single
|
||||||
|
# container, so the web process is always the worker too.
|
||||||
|
plugin :solid_queue if ENV.fetch("RAILS_ENV", "development") == "production"
|
||||||
|
|
||||||
# Specify the PID file. Defaults to tmp/pids/server.pid in development.
|
# Specify the PID file. Defaults to tmp/pids/server.pid in development.
|
||||||
# In other environments, only set the PID file if requested.
|
# In other environments, only set the PID file if requested.
|
||||||
|
|||||||
Reference in New Issue
Block a user