Skip to content

KWargs issue with mustermann gem preventing JRuby 10.0.1.0 upgrade #8920

@NC-piercej

Description

@NC-piercej

Environment Information

JRuby: 10.0.1.0 (via jruby:10.0.1.0-jdk21 docker image)

Using Sinatra 4.1.1 with the mustermann gem at 3.0.3

Expected Behavior

We expect no regressions from JRuby 10.0.0.1.

Actual Behavior

When running unit tests for the controller using Rack::Test::Methods:

     Failure/Error:
       post "services/#{service_name}/#{version}", body, {
         "Content-Type": "application/octet-stream"
       }
     
     ArgumentError:
       wrong number of arguments (given 2, expected 1)
     Shared Example Group: "endpoint configuration route" called from ./spec/controllers/services_controller_spec.rb:63
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/ast/parser.rb:17:in 'parse'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/ast/pattern.rb:91:in 'block in to_ast'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/equality_map.rb:43:in 'fetch'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/ast/pattern.rb:90:in 'to_ast'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/ast/pattern.rb:130:in 'param_converters'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/ast/pattern.rb:124:in 'map_param'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/pattern.rb:207:in 'block in params'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/pattern.rb:207:in 'block in params'
     # /usr/local/bundle/gems/mustermann-3.0.3/lib/mustermann/pattern.rb:206:in 'params'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1105:in 'process_route'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1072:in 'block in route!'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1069:in 'route!'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1193:in 'block in dispatch!'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1164:in 'invoke'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1188:in 'dispatch!'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1004:in 'block in call!'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1164:in 'invoke'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1004:in 'call!'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:993:in 'call'
     # /usr/local/bundle/gems/rack-protection-4.1.1/lib/rack/protection/base.rb:53:in 'call'
     # /usr/local/bundle/gems/rack-protection-4.1.1/lib/rack/protection/xss_header.rb:20:in 'call'
     # /usr/local/bundle/gems/rack-protection-4.1.1/lib/rack/protection/path_traversal.rb:18:in 'call'
     # /usr/local/bundle/gems/rack-protection-4.1.1/lib/rack/protection/base.rb:53:in 'call'
     # /usr/local/bundle/gems/rack-protection-4.1.1/lib/rack/protection/base.rb:53:in 'call'
     # /usr/local/bundle/gems/rack-protection-4.1.1/lib/rack/protection/frame_options.rb:33:in 'call'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/middleware/logger.rb:17:in 'call'
     # /usr/local/bundle/gems/rack-3.1.16/lib/rack/head.rb:15:in 'call'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:227:in 'call'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:2138:in 'call'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1677:in 'block in call'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1898:in 'synchronize'
     # /usr/local/bundle/gems/sinatra-4.1.1/lib/sinatra/base.rb:1677:in 'call'
     # /usr/local/bundle/gems/rack-test-2.2.0/lib/rack/test.rb:360:in 'process_request'
     # /usr/local/bundle/gems/rack-test-2.2.0/lib/rack/test.rb:163:in 'custom_request'
     # /usr/local/bundle/gems/rack-test-2.2.0/lib/rack/test.rb:112:in 'post'
     # ./spec/controllers/services_controller_spec.rb:21

Notably, this also occurs when we actually run the server, with the same stack trace.

Perusing the mustermann code, seems likely to be a hash-vs-kwargs issue of some sort in the newer version of JRuby. Given that there are no reported issues on CRuby, this is likely a JRuby-specific issue on 10.0.1.0.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions