ActionDispatch::ParamsParser replacement after upgrade to Rails 5 - ruby-on-rails

Migrating an app from Rails 4.2.9 to 5.2.1.
This is latest issue:
$ rails console
/Users/meltemi/rails/myapp/config/initializers/disable_xml_params.rb:3:in `<top (required)>': uninitialized constant ActionDispatch::ParamsParser (NameError)
from /Users/meltemi/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/railties-5.2.1/lib/rails/engine.rb:657:in `block in load_config_initializer'
from /Users/meltemi/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/activesupport-5.2.1/lib/active_support/notifications.rb:170:in `instrument'
from /Users/meltemi/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/railties-5.2.1/lib/rails/engine.rb:656:in `load_config_initializer'
The offending line of code in an initializer:
# config/initializers/disable_xml_params.rb
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML)
Rails Guides says:
ActionDispatch::ParamsParser is deprecated and was removed from the middleware stack. To configure the parameter parsers use ActionDispatch::Request.parameter_parsers=. (commit, commit)
So I've tried the following:
ActionDispatch::Request.parameter_parsers.delete(Mime::XML)
But that begets more errors:
$ rails console
/Users/meltemi/rails/myapp/config/initializers/disable_xml_params.rb:3:in `<top (required)>': uninitialized constant Mime::XML (NameError)
from /Users/meltemi/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/railties-5.2.1/lib/rails/engine.rb:657:in `block in load_config_initializer'
from /Users/meltemi/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/activesupport-5.2.1/lib/active_support/notifications.rb:170:in `instrument'
from /Users/meltemi/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/railties-5.2.1/lib/rails/engine.rb:656:in `load_config_initializer'
Is there a better way to call .delete on that object?

You have to grab the existing values from parameter_parsers, modify it to suit your needs, then reset the values to your modified values. From the ActionDispatch::Http::Parameters documentation:
parameter_parsers=(parsers)
Configure the parameter parser for a given MIME type.
It accepts a hash where the key is the symbol of the MIME type and the value is a proc.
original_parsers = ActionDispatch::Request.parameter_parsers
xml_parser = -> (raw_post) { Hash.from_xml(raw_post) || {} }
new_parsers = original_parsers.merge(xml: xml_parser)
ActionDispatch::Request.parameter_parsers = new_parsers
In your specific case, you should look at the parsers in original_parsers to see if there is anything to delete. On a simple Rails 5 app that I have handy to look at, the only values I have are:
=> {
:json => #<Proc:0x00007fe818fc6fb8#/Users/foo/.rvm/gems/ruby-2.6.0-preview2/gems/actionpack-5.2.1/lib/action_dispatch/http/parameters.rb:11 (lambda)>
}
Your app's configuration is likely different, but to answer your question about how to delete a value, this simple version should work:
ActionDispatch::Request.parameter_parsers = ActionDispatch::Request.parameter_parsers.except(:json)
You may find additional useful information in this answer.

Related

No implicit conversion of Nil to String Error with Paperclip

In my app I've created a view which lists all the PDFs in my S3 Bucket, and for this I am using the Paperclip Gem. However I am now receiving this error in my terminal.
Error performing Courts::SyncronizeBucketJob (Job ID: 8424356c-9717-4cca-9d76-4b157bab1065) from DelayedJob(default) in 450.5ms: TypeError (no implicit conversion of nil into String):
/Users/conorquarry/RubymineProjects/pair/app/_modules/courts/models/ocr_document.rb:46:in `initialize'
/Users/conorquarry/RubymineProjects/pair/app/_modules/courts/models/ocr_document.rb:46:in `new'
/Users/conorquarry/RubymineProjects/pair/app/_modules/courts/models/ocr_document.rb:46:in `block in <class:OcrDocument>'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/interpolations.rb:35:in `block (2 levels) in interpolate'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/interpolations.rb:35:in `gsub!'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/interpolations.rb:35:in `block in interpolate'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/interpolations.rb:34:in `each'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/interpolations.rb:34:in `interpolate'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/attachment.rb:556:in `interpolate'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/attachment.rb:171:in `path'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/storage/s3.rb:355:in `block in flush_writes'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/storage/s3.rb:352:in `each'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/storage/s3.rb:352:in `flush_writes'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-6.0.0/lib/paperclip/attachment.rb:247:in `save'
/Users/conorquarry/.rvm/gems/ruby-2.5.1/gems/paperclip-meta-3.1.0/lib/paperclip-meta/attachment.rb:13:in `save'
Looking at the Paperclip Interpolation Documentation I can't see my error, does anyone have an idea of where I should start? Below is the code throwing me the error.
Paperclip.interpolates :document_folder_name do |a, _s|
Pathname.new(a.instance.object_key).dirname.to_s
end
The error is reproducible by:
Pathname.new(nil)
So in this situation, a.instance.object_key is nil.
From the interpolations doc, a.instance will be the activerecord (or whatever ORM you're using) model that's trying to generate a paperclip path that includes :document_folder_name in it.
I'd guess #object_key is a method defined on your activerecord model and is returning nil.
You can put a pry / debugger or a print statement inside that block to see what the object is, then it should be fairly easy to write a unit spec for that method to ensure it returns the correct string.
In theory calling object_key.to_s would fix the error but would mean that :document_folder_name would interpolate to an empty string when paperclip is calculating the folder path, which may not be desirable.

Why is gsub complaining about nil when my object isn't nil?

I’m using Rails 4.2.7 and have the following to trim all white space from a particular expression …
puts "division: #{division}$$"
division = division.gsub(/\A\p{Space}+|\p{Space}+\z/, '')
when I run this, eventually my program dies with this output …
division: 18-29$$
Error during processing: undefined method `gsub' for nil:NilClass
/Users/mikeb/Documents/workspace/runtrax/app/models/race_time.rb:27:in `block in <class:RaceTime>'
/Users/mikeb/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:448:in `instance_exec'
/Users/mikeb/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:448:in `block in make_lambda'
/Users/mikeb/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:228:in `block in halting_and_conditional'
/Users/mikeb/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:506:in `block in call'
/Users/mikeb/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:506:in `each'
/Users/mikeb/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:506:in `call'
/Users/mikeb/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
…
I don’t understand why gsub thinks its getting a nil when the line above, the string is clearly not empty (a value of 18-29 is printed out). Curiously, I can’t reproduce this in a Rails console, so I’m wondering it here’s something else going on or if there’s a better way to write the above.
Some thoughts:
gsub is a method on strings. test out the type for "division" with this: puts division.class you may find that while "division" is not "nil," it may not be a string so it's throwing an error. see HERE for more description.
since your code is meant to change the value of division, you can do so more elegantly and economically using a "destructive method" as follows: division.gsub!(/\A\p{Space}+|\p{Space}+\z/, '') See HERE for a discussion of destructive methods (note the "!", also called "bang"). This probably doesn't solve the original question, but it does pretty up your code.

Dir.glob with sort issue

As in "Alphabetize results of Dir.glob", I use sort to get file list in alphabetical order:
Dir.glob("#{options[:path]}/**/*.jpg", File::FNM_CASEFOLD).sort { |file|
dir, filename = file.match(/.+\/(.+)\/(.+)/).captures
# ---cut---
}
Without the sort it works good, but with it fails with error:
$ rake slides:import -- --user foo --path /bar/baz
(in /home/user/app_folder)
"baz/ - /bar/baz/DSC_4120.JPG - saved"
rake aborted!
ArgumentError: comparison of String with 0 failed
/home/footoo/footoo/lib/tasks/slides.rake:41:in `>'
/home/footoo/footoo/lib/tasks/slides.rake:41:in `sort'
/home/footoo/footoo/lib/tasks/slides.rake:41:in `block (2 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `eval'
/usr/local/rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => slides:import
Any idea what's wrong ?
Full code available on Github.
When sort is given a block it expects it to return -1,0 or 1 in order to know how to sort (a custom <=> function). You need to add each after sort to get back the default sort and the intended behavior.
Dir.glob("#{options[:path]}/**/*.jpg", File::FNM_CASEFOLD).sort.each{|file|
....
}
Read the documentation here: http://ruby-doc.org/core-2.2.0/Array.html#method-i-sort

rails encoding issue =(

i use rails 2.3.9 with ruby 1.9.2 and when i trying to update my model with some russian letters i have error in unicorn log:
Error during failsafe response: incompatible character encodings: UTF-8 and ASCII-8BIT
Read error: #<NoMethodError: undefined method `[]' for nil:NilClass>
trace look like this:
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:521:in
process_client'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:594:in
block in worker_loop'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:592:in
each'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:592:in
worker_loop'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:482:in
block (2 levels) in
spawn_missing_workers'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:479:in
fork'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:479:in
block in spawn_missing_workers'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:475:in
each'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:475:in
spawn_missing_workers'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:489:in
maintain_worker_count'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn/http_server.rb:299:in
join'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/lib/unicorn.rb:13:in
run'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/gems/unicorn-3.0.1/bin/unicorn_rails:208:in
<top (required)>'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/bin/unicorn_rails:19:in
load'
/home/rbdev/.rvm/gems/ruby-1.9.2-p0#rails2/bin/unicorn_rails:19:in
`'
so, i can't detirminate the problem, the only thing i know - what problem in russia text ( when i update model with english letters - all is ok. what i can do ? (
You should ensure that your editor saves files in UTF-8. ASCII afaik is the first part of any charset. That should be the reason you don't get any errors when you leave out the russian chars.
I answered this one here, with a script. Why are all strings ASCII-8BIT after I upgraded to Rails 3?
You need
# coding: UTF-8
at the top of your files, with ruby 1.9. If that doesn't help, it might be your external dependency, such as DB.
you can use gem "russian" (gem is based on l18n)
https://github.com/yaroslav/russian
in model (instead of russian letters):
Russian::translate(:some_word)
in config file (must be encoded in UTF-8):
ru:
some_word: 'это строка с русскими буквами (this is string with russian letters)'

When working with gems in Rails, what does 'cannot remove Object::ClassMethods' stem from?

Frequently I have run into a problem when installing gems that provides a problem like:
Does anyone know what this stems from? I've seen in it several different cases, yet still haven't learned what exactly is causing it.
$ sudo rake gems:install --trace
(in /u/app/releases/20100213003957)
** Invoke gems:install (first_time)
** Invoke gems:base (first_time)
** Execute gems:base
** Invoke environment (first_time)
** Execute environment
rake aborted!
cannot remove Object::ClassMethods
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_const'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `instance_eval'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:603:in `remove_constant'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `each'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:549:in `new_constants_in'
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/misc.rake:4
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
/u/app/releases/20100213003957/vendor/rails/railties/lib/tasks/gems.rake:17
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in `invoke_task'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1974:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
I believe I've found a practical non-intrusive method to get at the root of the problem. It works for me (Rails 2.3) :
As it happens Exception#blame_file! is invoked at some point in spite of the fact that it will fail and cause a new error, thus masking the original error.
So, open your FIRST initializer and add,
class Exception
def blame_file!( file )
puts "CULPRIT >> '#{file.to_s}' # #{self.to_s}"
end
end
You'll get both the incriminated file and the original error message. That should be enough to pinpoint your problem.
Don't forget to remove the Exception initializer snippet.
The cause of this error is a double exception. Usually something in your code is crashing, which raises an initial exception. Then Rails' custom require attempts to keep the namespace clean by removing partially defined constants, which is the purpose of the new_constants_in method. The problem is that new_constants_in is not properly handling some particular construction somewhere within the code, I suspect due to mishandling of module namespaces or something (because ClassMethods is probably inside some module other than Object). In any case, I have not traced the error back to a Rails component or anything else, because frankly it's not worth the effort.
The solution (short of proposing something a little less invasive to Rails core) is a quick hack to figure out what raised the original exception. All you need to do is go to where Dependencies.new_constants_in is called and comment it out (there are a few places where this could be). So for example:
def require(file, *extras) #:nodoc:
if Dependencies.load?
Dependencies.new_constants_in(Object) { super }
else
super
end
rescue Exception => exception # errors from required file
exception.blame_file! file
raise
end
Comment out the new_constants_in stuff:
def require(file, *extras) #:nodoc:
# if Dependencies.load?
# Dependencies.new_constants_in(Object) { super }
# else
super
# end
#rescue Exception => exception # errors from required file
# exception.blame_file! file
# raise
end
Then you'll see your error straight away.
I just came across this problem again. After some debugging I came to this conclusion: this weird error means that Rails has some troubles with requiring some particular library. The problem is that Rails doesn't tell us which library causes the problem. So, the first step you have to do is this:
Open this file (or the appropriate file in your installation):
/u/app/releases/20100213003957/vendor/rails/activesupport/lib/active_support/dependencies.rb
and edit the load_with_new_constant_marking method so it looks like this:
def load_with_new_constant_marking(file, *extras) #:nodoc:
if Dependencies.load?
Dependencies.new_constants_in(Object) { load_without_new_constant_marking(file, *extras) }
else
load_without_new_constant_marking(file, *extras)
end
rescue Exception => exception # errors from loading file
puts "FAILS HERE: " + file
exception.blame_file! file
raise
end
From now on, when running your application or a rake task, instead of just telling you that it "cannot remove Object::ClassMethods" Rails will tell you which file causes the problem (just look for the "FAILS HERE" statement). (Btw. I suppose this is what the exception.blame_file! method should be doing, but it obviously doesn't work that way.)
After you have located the file which causes the problem, you can dig into that particular chunk and use some exception blocks to get to the core of the problem.
Hope this helps.
I also started catching this bizarre error today -- traced it back to an out-of-date mysql gem .
I'd just switched from using the Mac MySQL package (the one that comes with a PrefPane) to a Homebrew-compiled version and the old /usr/local/mysql was lingering in my PATH
Deleting that directory (and other traces of the old MySQL) and then re-bundling my app solved it!
I ran into this issue, and tried each of the above solutions, but to no avail.
In my case, the problem was that I had accidentally included ActionView::Helpers::TextHelper and ActionView::Helpers::NumberHelper at the top of a file (thereby including them into the root Object class), this worked OK in Rails 3.0.0.rc, but raised the "cannot remove Object::ClassMethods" in Rails 3.0.1, and once raised, the app remained stuck until the server was restarted.
This started happening with me, but only after I included the delayed_job gem in my bundle. Like Eric above, I included ActionView::Helpers::TextHelper and ActionView::Helpers::NumberHelper at the top of a controller, but the funny thing is that I had no problems whatsoever until I started using delayed_job. I've no idea what's going on, I just removed the includes and the problem seems to have disappeared.

Resources