fix access priorities of each level in LeveledOptions (#1118)

[MitchLewis930]

User description

PR_056

---

PR Type

Bug fix

---

Description

• Fix access priority order in LeveledOptions by reversing iteration

• Ensures most recently added options take precedence over defaults

• Add test case for option override behavior verification

---

Diagram Walkthrough

flowchart LR
  A["LeveledOptions[]<br/>access method"] -->|changed iteration| B["reverse_each<br/>instead of each"]
  B -->|result| C["Latest options<br/>checked first"]
  C -->|behavior| D["Overrides take<br/>precedence"]

Loading

File Walkthrough

	Relevant files
Bug fix	configuration.rb Reverse iteration order for option lookup                                lib/puma/configuration.rb Changed @set.each to @set.reverse_each in the [] method Reverses iteration order to check most recently added options first Ensures user-provided options override default configuration values +1/-1
Tests	test_config.rb Add test for option override behavior                                        test/test_config.rb Added new test method test_overwrite_options Tests that configuration options can be overwritten after loading Verifies that modified option values persist correctly +11/-0

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Provide default fallback option Modify the [] method in LeveledOptions to fall back to @defaults[key] if the key is not found in the @set of user-provided options. lib/puma/configuration.rb [33-38] def [](key) @set.reverse_each do |o| - if o.key? key - return o[key] - end + return o[key] if o.key?(key) end + @defaults[key] end Apply / Chat Suggestion importance[1-10]: 9 __ Why: This suggestion correctly identifies a significant omission in the [] method; without falling back to @defaults, the default options are never used, which is likely a bug.	High
General	Isolate write operation in test In test_overwrite_options, replace conf.options[:workers] += 1 with a direct assignment like conf.options[:workers] = 4 to create a more isolated test for the write operation. test/test_config.rb [67] -conf.options[:workers] += 1 +conf.options[:workers] = 4 Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly points out that using += tests both read and write operations, and replacing it with a direct assignment improves test isolation, which is a good practice.	Low
	Simplify loop condition Refactor the reverse_each loop in the [] method into a single line to improve conciseness. lib/puma/configuration.rb [34-38] -@set.reverse_each do |o| - if o.key? key - return o[key] - end -end +@set.reverse_each { |o| return o[key] if o.key?(key) } Apply / Chat Suggestion importance[1-10]: 2 __ Why: This is a minor stylistic suggestion that changes a multi-line block to a single line, which is a matter of preference and has no functional impact.	Low
More