MushroomObserver / mushroom-observer / 29040534895
99%
main: 99%

LAST BUILD BRANCH: nimmo-inline-import-source-notice
DEFAULT BRANCH: main
Ran
Jobs 1
Files 1723
Run time 4min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 99.107%. Remained the same
29040534895

Pull #4750

github

nimmolo 
Guard against Solid Queue's thread-pool-vs-DB-pool crash (prod incident)

Production's config/database.yml (gitignored, not tracked -- the actual
fix had to be applied directly on the server) never set an explicit
`pool:` for its production environment, so it silently used
ActiveRecord's default of 5. That was fine while Solid Queue's busiest
worker needed 3 threads + 2 (worker + heartbeat) = 5, but #4727 bumped
that worker's threads to 4, needing 6 -- one more than the pool had.

SolidQueue::Configuration#ensure_correctly_sized_thread_pool validates
this at supervisor startup and refuses to run if the pool is too
small. With `Restart=always` in the systemd unit, this meant every
single (re)start of the supervisor failed instantly and got respawned
again a few seconds later, forever -- no queue was ever claimed again
after whatever first restart picked up the new thread count. Nothing
in the app surfaces this at boot time normally; it only shows up if
something actually asks Solid Queue to validate its own configuration.

Since config/database.yml isn't checked in, there's no code fix for
production's own file here -- that's been corrected directly on the
server. What *is* fixable here: db/vagrant/database.yml, which CI
copies to config/database.yml for test runs, had the exact same latent
gap (test env's effective pool was also 5). Bumped it to 10, and added
a regression test that actually instantiates SolidQueue::Configuration
for the current environment and asserts it's valid -- so this class of
bug (thread count outpacing the connection pool) gets caught by CI the
next time either side of that ratio changes, instead of only
surfacing as a silent production crash loop.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pull Request #4750: Guard against Solid Queue thread-pool-vs-DB-pool crash (prod incident)

51742 of 52208 relevant lines covered (99.11%)

748.92 hits per line

Jobs
ID Job ID Ran Files Coverage
1 29040534895.1 1723
99.11
 GitHub Action Run
Source Files on build 29040534895