I see how this is useful but I'm a tiny bit worried that this may hide the configuration errors from the user. Maybe this should be part of Puma v7.

I think I'd expect this to work like --workers "" which doesn't blow up, but parses it to 0 internally. Same outcome as this PR specifying WEB_CONCURRENCY="" (or WEB_CONCURRENCY= for shorthand.)

It'll fall back to 0 if nothing is specified in the concurrency, so I don't think this will hide mis-configuration issues. If you're setting a variable to nothing and then nothing is being configured it's correct.

Not from puma's internals, but I found a bug in a config/puma.rb recently where setting WEB_CONCURRENCY=2 caused the app to not boot. Specifying nothing caused it to successfully boot with two workers. (We were reading the environment variable but not casting to Integer before checking if greater than 1. ArgumentError.)

I wonder if I might be slightly special in how I use the shell, but having run into this with both a crappy config file of my own making, and natively with Puma 6 and the internals exploding I figured I'd raise the PR.

The case where it's overridden in one command locally for testing purposes was where our app specifies WEB_CONCURRENCY=2 in our local .env file, so we run with two workers in development. Whilst testing something else I wanted to run with no workers so it was all in same process. The shorthand in shell for unsetting an environment variable is to just set it to nothing (ie, "") rather than unset FOO; command; export FOO=$original for completeness. Except kaboom in this case.

Also (tongue in cheek 😛) if you squint in the right way, this is a regression in behaviour. Puma 4 runs fine, then Puma 5 blows up.

$ WEB_CONCURRENCY= BUNDLE_GEMFILE=Gemfile.puma4 bundle exec puma
Puma starting in single mode...
* Version 4.3.12 (ruby 3.3.5-p100), codename: Mysterious Traveller
* Min threads: 0, max threads: 16
* Environment: development
ERROR: No application configured, nothing to run

$ WEB_CONCURRENCY= BUNDLE_GEMFILE=Gemfile.puma6 bundle exec puma
bundler: failed to load command: puma (/Users/caius/.asdf/installs/ruby/3.3.5/lib/ruby/gems/3.3.0/bin/puma)
<internal:kernel>:307:in `Integer': invalid value for Integer(): "" (ArgumentError)
	from /Users/caius/.asdf/installs/ruby/3.3.5/lib/ruby/gems/3.3.0/gems/puma-6.4.3/lib/puma/configuration.rb:233:in `puma_options_from_env'

Mostly I think it should behave the same as --worker "" and also not blow up when overriding an existing value in shell - fall back to good defaults at that point.

Fixed the jruby tests and corrected the first commit to say "max", not "min".

I think I'd expect this to work like --workers "" which doesn't blow up, but parses it to 0 internally

I did not know that – then I agree, this sounds more like a bug fix

This conflicted with #3550. Rebased and fixed the merge issues.