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:
Dan Milne
2026-05-02 23:51:37 +10:00
parent 7d352654fd
commit 09e9b32e46
2 changed files with 3 additions and 5 deletions

View File

@@ -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

View File

@@ -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.