Fixup code for use with rackup gem (may be used with rack 3) (#3061)

[MitchLewis930]

User description

PR_060

---

PR Type

Enhancement, Tests

---

Description

• Add Rack 3 and Rackup gem compatibility support

• Refactor handler code to use module inclusion pattern

• Update tests to support both Rack 2 and Rackup/Rack 3

• Add conditional gem dependency for rackup in Gemfile

---

Diagram Walkthrough

flowchart LR
  A["Rack/Rackup Detection"] -->|Rackup available| B["Rackup::Handler::Puma"]
  A -->|Rack 2| C["Rack::Handler::Puma"]
  A -->|Rack 3 only| D["Error: Install Rackup"]
  E["Puma::RackHandler Module"] -->|include| B
  E -->|include| C
  F["Test Configuration"] -->|PUMA_CI_RACK_2| C
  F -->|Default| B

Loading

File Walkthrough

	Relevant files
Enhancement	rack_default.rb Add Rack 3 and Rackup compatibility detection                        lib/puma/rack_default.rb Add conditional logic to detect Rackup gem vs Rack version Define handler for Rackup module when available Define handler for Rack module when Rack < 3 Raise error when Rack 3 is used without Rackup gem +18/-3    puma.rb Refactor handler to support multiple Rack versions              lib/rack/handler/puma.rb Extract handler methods into reusable Puma::RackHandler module Change from self. methods to instance methods for inclusion Add conditional module registration for Rackup and Rack handlers Use include pattern instead of direct module definition +116/-94
Tests	test_rack_handler.rb Update tests for Rack 2 and Rackup compatibility                  test/test_rack_handler.rb Add environment variable check for Rack 2 vs Rackup/Rack 3 Define RACK_HANDLER_MOD constant to abstract handler module Update all test assertions to use RACK_HANDLER_MOD instead of hardcoded Rack::Handler Wrap tests in TestRackUp module for conditional execution +28/-23
Dependencies	Gemfile Add rackup gem dependency for Rack 3                                          Gemfile Add conditional dependency on rackup gem Only include rackup when not using Rack 2 (via PUMA_CI_RACK_2 env var) +1/-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: 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
🔴	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: 🏷️ Version comparison bug: The code compares Rack::RELEASE as a string (e.g., Rack::RELEASE < '3'), which can mis-detect Rack versions and lead to incorrect handler selection or unexpected runtime errors. Referred Code elsif Object.const_defined?(:Rack) && Rack::RELEASE < '3' module Rack 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	Use semantic version comparison Use Gem::Version for comparing the Rack::RELEASE version to prevent incorrect behavior with future Rack versions due to string comparison limitations. lib/puma/rack_default.rb [14] -elsif Object.const_defined?(:Rack) && Rack::RELEASE < '3' +elsif Object.const_defined?(:Rack) && ::Gem::Version.new(Rack::RELEASE) < ::Gem::Version.new('3') Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly points out that string comparison for versions is buggy (e.g., '10.0' < '3') and proposes using Gem::Version for a robust, semantic comparison, which prevents future breakage.	High
General	Improve error message for Rack 3 Refine the error-raising logic to explicitly check for Rack version 3 or higher, preventing a confusing error message when Rack is not defined at all. lib/puma/rack_default.rb [22-24] -else +elsif Object.const_defined?(:Rack) && Rack::RELEASE >= '3' raise "Rack 3 must be used with the Rackup gem" end Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that the else block could be triggered when Rack is not defined, leading to a confusing error message. Making the condition explicit improves the robustness and clarity of the error handling.	Low
More