Ensure puma config load process is respected #2794
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ref: puma/puma#3616
In v7, puma will be validating that its config objects are both loaded (loads config files) and clamped (resolves config procs and finalizes defaults) before its options are accessed to begin the launch process. This will be a breaking change for users utilising capybara as it builds its own puma config, but only clamps it. This change ensures a future version of capybara can be compatible with puma v7, while also being backward compatible with previous versions.
Note: The side effect of this change is that options specified in users' puma config files that are not specified in capybara's user options will be taken into account when capybara boots its server. A workaround would be to only pass in the user options hash here (
conf.options.user_options
) so only those options will be picked up by puma and merged with its default options. Let me know what you think.