Padrino (v. 0.15.3) fails to start with Ruby 3.3.0: uninitialized constant Padrino::Rackup (NameError) #2288
Comments
|
@achiurizo would this be fixed with a release from master? Would be great to cut a release that supports Ruby 3.3 |
|
Something to mention is that I am using the git repository as a source code, I mean, in my Gemfle it is as follows: |
|
@kimberlykeilymh thank you for the report! I've pushed out #2289 which should resolve this (adds @nesquena we should do more testing after #2289 but after that I think we can go ahead and cut a release |
|
I went ahead and merged that change. Let us know if that fixes things for you. If everything is working as expected, we can do final testing and cut a release |
|
Thanks guys! The change fixed the bug with Although now I get this other error: Is it also possible to check this error? I can open another issue and close this one if you want. |
|
@achiurizo hmm, looks like rack_options is nil rather than a hash now in the server start sequence |
|
@nesquena I built a Padrino app from scratch with limited changes to config (updating database) — using Edge release w/ the inclusion of Backup in the Gemspec results in the issue @kimberlykeilymh mentioned above. Prior to using the Edge release, I was using the default release and included Backup using |
|
As a starting point, thanks @srolandmarshall I don't want to be too optimistic but it seems like part of this may just be a change to the way Rack parses the files. I had rack options default to {} on #2290 (branch nesquena-rack-options-fix) until achiu may have a chance to test end to end It's possible this would fix it, but also possible and likely there's larger changes to Rack that need to be adjusted in the core server startup sequence |
|
Checked it out, seemed to solve the problem on my end. Thanks for the quick patch @nesquena |
|
Great, thanks for testing! @achiurizo can you merge my PR, and @kimberlykeilymh can you try my patch as well and report back either now or after we merge to master |
|
Hi guys! Yes, that solved the problem and padrino is running without errors. Thanks very much for the fix! |
|
That's great news, thanks for testing! Since two of you confirmed, perhaps it's time to cut a new release soon |
|
Hi! Any news on a new release of Padrino? |
|
I'll push out a new release with these fixes within a week |
|
Okay I pushed out release 0.16.0.pre2 which appears compatible with latest Rack and Ruby - can one or two of you try this and report back confirming everything works as it should? @floriandejonckheere @achiurizo @kimberlykeilymh @srolandmarshall As soon as I get confirmations, I'll cut it as an official release! If anyone wants to help fix the CI to pass the tests fully, that would be appreciated as well 😅 |
|
Hi folks! Thanks for pushed out a new version! |
|
Based on this part of the error:
I wonder if you could try adding the "puma" gem or thin to the Gemfile of your app, run bundle and then try starting it up again? Does that change anything? |
|
Something I forgot to mention is that we use WEBrick as a server, which is part of the server list. |
|
Trying with Puma and thin I got the same error |
|
Thanks @kimberlykeilymh for testing! I'm glad I did this as a pre release 😅 And once we figure out this issue, get all the tests passing, and confirm things are looking good, I'll push an official version |
|
@achiurizo Any idea what might be going on above? |
|
Pushed pre3 @kimberlykeilymh Can you try again with the latest pre3 release and confirm that everything works as expected now? |
|
Hi Nathan! @nesquena On the other hand, I had an error with this new version regarding the parameters received by the controller. In one of the forms we have fields nested in two levels that reach the controller in the following way: But now those same parameters are obtained like this: At the form level the name of the fields remains the same ( This would be for example for an Do you have any idea what could be happening? Is there some new definition in the framework that does not allow nesting in more than one level? Thanks in advance, |
|
Thanks so much for testing @kimberlykeilymh and catching the issue with nested form parameter processing. That seems like a bug. Before we release, we'll fix this so that it matches the original behavior If anyone can help investigate, and or write tests for this, or fix any other failing tests, that would be appreciated Before this next major release, we'll also need to fix all failing tests and test a number of apps work as expected. But glad we are making some progress 😊 |
|
Building on @kimberlykeilymh's issue, here's what I'm getting when I try to deploy to heroku running Ruby 3.2.5 NameError: uninitialized constant Rack::Server (NameError) class Server < Rack::Server (See full trace by running task with --trace) |
|
Can anyone help? I and ChatGPT are at a loss on how to fix this. I've just been trying to update my sinatra/padrino app to run on the latest heroku stack which runs 3.2.5 |
|
I definitely keep getting the same error and I'm stuck. /Users/rasheqrahman/.rvm/gems/ruby-3.2.5/gems/padrino-core-0.15.3/lib/padrino-core/server.rb:34:in `module:Padrino': uninitialized constant Rack::Server (NameError) class Server < Rack::Server |
|
@rasheqrahman you are using padrino 0.15.3 and as discussed here, 0.16.0.pre3 should fix |
|
Hi @kimberlykeilymh 👋 I am not able to replicate the error you are seeing with nested models. I created a dummy app with Padrino 0.16.0.pre3 version with nested models and forms. However, I am receiving the nested params in the correct way. Could it be something with the form helpers you are using? I used |
|
Thanks for testing this @chaymaeBZ 🙏 , and I'll be happy to release the next version in full outside of pre once we feel confident tests are passing again and that all critical bugs have been worked out. I haven't had time unfortunately to dig deep into the nested forms issue yet, I wasn't able to reproduce with a simple nested example, but perhaps it's like second layer nesting where it's failing? |
|
Thanks @nesquena! indeed I could replicate this! I wrote simple steps to reproduce it :
NestedParamsExample::App.controllers :example do
post :submit do
"params received: #{params.inspect}"
end
end(remove csrf protection from
|
|
Thank you, that is really helpful, this may be one of the last major issues before we can release the new version. If anyone has a chance to review and put in a fix for this nested form parsing issue, I'd be happy to review and merge and cut a release once kimberly confirms the fix. I'll try to find time to fix it myself eventually. Also any work to fix broken tests is appreciated too Thanks to everyone for your help |
|
I did a deep dive into this. As I suspected, this has nothing to do with Padrino. This behavior comes from Rack. And this change was introduced in Rack 3. You can try the same workflow with Sinatra 4 and it will yield the same 'weird' result. Now this not a bug. In fact, it's only weird to set nested params as The recommended way to send your nested fields is to use You can try it, switching between # rack 3
Rack::Utils.parse_nested_query "account[account_settings[example_field]]=value"
#=> {"account"=>{"account_settings[example_field"=>{"]"=>"value"}}}
# rack 2
Rack::Utils.parse_nested_query "account[account_settings[example_field]]=value"
#=> {"account"=>{"account_settings"=>{"example_field"=>"value"}}}
Rack::Utils.parse_nested_query "account[account_settings]example_field=value"
#=> {"account"=>{"account_settings"=>{"example_field"=>"value"}}}The change has been introduced here, where it tries to "scan" for what's between Here is another way to test this behavior of rack require 'stringio'
require 'rack'
def get_params(input)
rack_input = StringIO.new(input)
env = {'rack.input' => rack_input, 'REQUEST_METHOD' => 'POST'}
request = Rack::Request.new(env)
request.params
end
correct_input = "account[account_settings][example_field]=value"
wrong_input = "account[account_settings[example_field]]=value"
p get_params(correct_input)
# => Rack 2 :
# => {"account"=>{"account_settings"=>{"example_field"=>"value"}}}
# => Rack 3 :
# => {"account"=>{"account_settings"=>{"example_field"=>"value"}}}
p get_params(wrong_input)
# => Rack 2 :
# => {"account"=>{"account_settings"=>{"example_field"=>"value"}}}
# => Rack 3 :
# => {"account"=>{"account_settings[example_field"=>{"]"=>"value"}}} |
|
I see, is it possible then that this is more of a won't fix? It may not be our responsibility to address this unless our own form helpers are generating incorrect code. What's your recommendation? AFAIK this may be the last known issue before I can cut a release. |
|
I'd say it's a won't fix thing. I wouldn't even call it a bug 😂 I tried with the form generators, it's not generating such weird nesting syntax. So I'd say it's up to people to fix any weird nesting syntax they hardcoded. |
|
@kimberlykeilymh can you share a snippet of your form? |
|
Hello everyone! Thank you for taking the time to review the potential error. = form_for @account, url_for(:accounts, :index, id: @account.id), method: :put do |f|
.form-group.row
= f.label 'account_settings[ex_integration_enabled]', caption: 'Integración EX', class: ['col-form-label', 'col-lg-2']
= f.check_box 'account_settings[ex_integration_enabled]', class: ['form-control', 'custom-control-input'], checked: !@account.account_settings&.value&.[]('ex_integration_enabled').nil?
(ruby) params[:account]
{"account_settings[mp_integration_enabled"=>{"]"=>"1"}}= form_for @account, url_for(:accounts, :index, id: @account.id), method: :put do |f|
.form-group.row
= f.label 'account_settings[ex_integration_enabled]', caption: 'Integración EX', class: ['col-form-label', 'col-lg-2']
= f.check_box '[account_settings][ex_integration_enabled]', class: ['form-control', 'custom-control-input'], checked: !@account.account_settings&.value&.[]('ex_integration_enabled').nil?
(ruby) params[:account]
{"[account_settings"=>{"mp_integration_enabled"=>{"]"=>"1"}}} |
|
@kimberlykeilymh you are using the form builders in a wrong way. If you inspect both forms, the first checkbox's name will look something like |
|
Thanks @chaymaeBZ for investigating this! @kimberlykeilymh can you try to make those adjustments to the form helpers and confirm everything works as expected, test around and give me confirmation that nothing appears broken? |
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Failure to start server using Ruby 3.3.0. Below is the stack trace.
What is the expected behavior?
Start the server without errors.
Which versions of Ruby, Padrino, Sinatra, Rack, OS are you using? Did this work in previous versions?
Ruby 3.3.0, Padrino 0.15.3, Ubuntu 23.10.
The text was updated successfully, but these errors were encountered: