You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Jobs and transactional integrity](#jobs-and-transactional-integrity)
32
33
-[Recurring tasks](#recurring-tasks)
33
34
-[Inspiration](#inspiration)
@@ -603,6 +604,30 @@ that you set in production only. This is what Rails 8's default Puma config look
603
604
604
605
**Note**: phased restarts are not supported currently because the plugin requires [app preloading](https://github.com/puma/puma?tab=readme-ov-file#cluster-mode) to work.
605
606
607
+
## Health-check HTTP server
608
+
609
+
Solid Queue provides a tiny HTTP health-check server that runs as a supervised process.
610
+
611
+
- Endpoints:
612
+
- `/` and `/health`:
613
+
- Returns `200 OK` with body `OK` when the supervisor and all supervised processes (workers, dispatchers, scheduler, and the health server itself) have fresh heartbeats.
614
+
- Returns `503 Service Unavailable` with body `Unhealthy` if any supervised process (or the supervisor) has a stale heartbeat.
615
+
- Any other path: returns `404 Not Found`
616
+
- Configure via `config/queue.yml` under `health_server:`. Both `host` and `port` are required.
617
+
618
+
Enable and configure via process configuration:
619
+
620
+
```yml
621
+
production:
622
+
health_server:
623
+
host: 0.0.0.0
624
+
port: 9393
625
+
```
626
+
627
+
Note:
628
+
- This runs under the supervisor just like workers/dispatchers.
629
+
- When the Puma plugin is active (`plugin :solid_queue` in `puma.rb`), the configured health server is skipped to avoid running multiple HTTP servers in the same process tree. A warning is logged. If you need the health server, run Solid Queue outside Puma (for example, via `bin/jobs`) or disable the plugin on that instance.
630
+
606
631
## Jobs and transactional integrity
607
632
:warning: Having your jobs in the same ACID-compliant database as your application data enables a powerful yet sharp tool: taking advantage of transactional integrity to ensure some action in your app is not committed unless your job is also committed and vice versa, and ensuring that your job won't be enqueued until the transaction within which you're enqueuing it is committed. This can be very powerful and useful, but it can also backfire if you base some of your logic on this behaviour, and in the future, you move to another active job backend, or if you simply move Solid Queue to its own database, and suddenly the behaviour changes under you. Because this can be quite tricky and many people shouldn't need to worry about it, by default Solid Queue is configured in a different database as the main app.
SolidQueue.logger&.warn("SolidQueue health server is configured but Puma plugin is active; skipping starting health server to avoid duplicate servers")
136
+
return[]
137
+
end
138
+
139
+
options=health_server_options
140
+
return[]unlessoptions
141
+
142
+
[Process.new(:health_server,options)]
143
+
end
144
+
145
+
defensure_valid_health_server
146
+
server_options=health_server_options
147
+
returnunlessserver_options
148
+
149
+
unlessserver_options[:host].present?
150
+
errors.add(:base,"Health server: host is required")
0 commit comments