Skip to content

Warn instead of raising when the connection pool is smaller than the thread pool#753

Open
ajaynomics wants to merge 1 commit into
rails:mainfrom
ajaynomics:fix/736-pool-size-warning
Open

Warn instead of raising when the connection pool is smaller than the thread pool#753
ajaynomics wants to merge 1 commit into
rails:mainfrom
ajaynomics:fix/736-pool-size-warning

Conversation

@ajaynomics

Copy link
Copy Markdown

What

Solid Queue refuses to boot when the database connection pool is smaller than the worker thread pool, raising a ConfigurationError. This PR makes the check advisory: Solid Queue boots and logs a warning instead.

Why

The hard cap rules out configurations that work well in practice. The reporter in #736 runs an I/O-bound queue — 150 threads making slow HTTP calls against a deliberately small pool — where each thread holds a connection only briefly. Today, booting that setup requires monkey-patching the check away.

As suggested in #736, this replaces the hard failure with a warning, which the reporter confirmed fits the need. (The issue also floated a config flag to bypass the check; an unconditional warning is simpler and adds no new configuration surface.)

How

  • Drop ensure_correctly_sized_thread_pool from the validation chain, so Configuration#valid? reflects only whether the configuration can boot.
  • Add Configuration#warn_about_undersized_thread_pool, which logs the advisory through SolidQueue.logger.
  • Call it from Supervisor.start, just after the valid? check. The bin/jobs CLI and both Puma plugin modes — forked and async — start through Supervisor.start, so the warning fires once on every boot path.

The warning text matches the previous error, so existing log filters and operator expectations still hold.

Tests

  • async_supervisor_test: booting with more threads than connections logs the warning; booting with enough connections stays silent. (Removing the call from Supervisor.start fails the first test.)
  • configuration_test: an undersized pool no longer makes the configuration invalid.

Closes #736.

…thread pool

Solid Queue refused to boot when the Active Record connection pool was
smaller than the worker thread pool. This blocked legitimate setups, such
as I/O-bound queues that run many threads against a deliberately small pool.

Per the discussion in rails#736, downgrade the check from a validation error to
a SolidQueue.logger warning emitted once on the boot path in
Supervisor.start, so undersized configurations boot while still surfacing
the advisory. valid? stays purely about whether we can boot.

Closes rails#736
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

There should be a way to bypass the connection pool vs worker threads check

1 participant