I'm maintaining a rails 2.1 application that has some unfortunate choices for column names. For instance, an Event has a start and an end date. Instead of using start_at and end_at the original design uses start and end. Of course this leads to
def end
read_attribute(:end) || 1.hour.from_now
end
I'm surprised this even parses. Is this legal ruby? The real issue is that erb is blowing up with 'stack level too deep' when running a backgroundrb job to send the reminder emails. The template is
<%= [#event.name, #event.when_pretty, #event.location, #event.association,
#event.notes].reject(&:blank?) * "\n" %>
If I deliver_reminder in the console there is no error, but when deliver_reminder is called during the background job, the error occurs.
Question: should I refactor to remove the end method, or is the stack error being caused by something else?
On line #1 of foo/mailer/reminder.rhtml
1: <%= [#event.name, #event.when_pretty, #event.location, #event.association, #event.notes].reject(&:blank?) * "\n" %>
lib/virtual_attributes_and_associations.rb:59:in `virtual_attribute_names'
lib/virtual_attributes_and_associations.rb:83:in `read_attribute_without_virtual'
lib/virtual_attributes_and_associations.rb:86:in `read_attribute'
vendor/rails/activerecord/lib/active_record/base.rb:2720:in `send'
vendor/rails/activerecord/lib/active_record/base.rb:2720:in `clone_attribute_value'
vendor/rails/activerecord/lib/active_record/dirty.rb:127:in `write_attribute'
vendor/rails/activerecord/lib/active_record/attribute_methods.rb:211:in `data='
lib/virtual_attributes_and_associations.rb:9:in `included'
vendor/rails/activesupport/lib/active_support/callbacks.rb:177:in `call'
vendor/rails/activesupport/lib/active_support/callbacks.rb:177:in `evaluate_method'
vendor/rails/activesupport/lib/active_support/callbacks.rb:161:in `call'
vendor/rails/activesupport/lib/active_support/callbacks.rb:93:in `run'
vendor/rails/activesupport/lib/active_support/callbacks.rb:92:in `each'
vendor/rails/activesupport/lib/active_support/callbacks.rb:92:in `send'
vendor/rails/activesupport/lib/active_support/callbacks.rb:92:in `run'
vendor/rails/activesupport/lib/active_support/callbacks.rb:272:in `run_callbacks'
vendor/rails/activerecord/lib/active_record/callbacks.rb:298:in `callback'
vendor/rails/activerecord/lib/active_record/base.rb:1450:in `send'
vendor/rails/activerecord/lib/active_record/base.rb:1450:in `instantiate'
vendor/rails/activerecord/lib/active_record/base.rb:582:in `find_by_sql'
vendor/rails/activerecord/lib/active_record/base.rb:582:in `collect!'
vendor/rails/activerecord/lib/active_record/base.rb:582:in `find_by_sql'
vendor/rails/activerecord/lib/active_record/base.rb:1341:in `find_every'
vendor/rails/activerecord/lib/active_record/base.rb:1376:in `find_one'
vendor/rails/activerecord/lib/active_record/base.rb:1362:in `find_from_ids'
vendor/rails/activerecord/lib/active_record/base.rb:537:in `find'
vendor/rails/activerecord/lib/active_record/associations/belongs_to_association.rb:44:in `find_target'
vendor/rails/activerecord/lib/active_record/associations/association_proxy.rb:196:in `load_target'
vendor/rails/activerecord/lib/active_record/associations/association_proxy.rb:99:in `reload'
vendor/rails/activerecord/lib/active_record/associations.rb:1084:in `contact'
lib/association.rb:52:in `associated_object'
lib/association.rb:48:in `association'
vendor/rails/activerecord/lib/active_record/associations/association_proxy.rb:177:in `send'
vendor/rails/activerecord/lib/active_record/associations/association_proxy.rb:177:in `method_missing'
app/views/foo/mailer/reminder.rhtml:1:in `_run_erb_47app47views47foo47mailer47reminder46rhtml'
Turns out the issue was with a library method called association, when I changed that to call associated_object (which was called by Association#association), the stack error no longer occurred.
Related
I have an Expenditure model:
class Expenditure < ApplicationRecord
multi_tenant :company
after_commit :related_reindex
def related_reindex
ExpenditureRelatedReindex.perform_async(id)
end
end
Here is my worker expenditure_related_reindex.rb:
class ExpenditureRelatedReindex
include Sidekiq::Worker
sidekiq_options :queue => :critical, :retry => true, :backtrace => true
def perform(record_id)
e = Expenditure.find(record_id)
MultiTenant.with(e.company) do
return unless e
e.expenditure_items.each(&:reindex)
e.children&.each(&:reindex)
end
end
end
The reindex can take some time so I want these to spin off to SideKiq. I have sime multi tenant code I should mention but I don't think it's the issue. After the record is updated I get:
NameError: uninitialized constant ExpenditureRelatedReindex
Did you mean? ExpenditureItemsHelper
from sidekiq/processor.rb:268:in `const_get'
from sidekiq/processor.rb:268:in `constantize'
from sidekiq/processor.rb:132:in `block (5 levels) in dispatch'
from sidekiq/rails.rb:43:in `block in call'
from active_support/execution_wrapper.rb:87:in `wrap'
from active_support/reloader.rb:73:in `block in wrap'
from active_support/execution_wrapper.rb:87:in `wrap'
from active_support/reloader.rb:72:in `wrap'
from sidekiq/rails.rb:42:in `call'
from sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
from sidekiq/processor.rb:257:in `stats'
from sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
from sidekiq/job_logger.rb:13:in `call'
from sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
from sidekiq/job_retry.rb:78:in `global'
from sidekiq/processor.rb:124:in `block in dispatch'
from sidekiq/logger.rb:10:in `with'
from sidekiq/job_logger.rb:33:in `prepare'
from sidekiq/processor.rb:123:in `dispatch'
from sidekiq/processor.rb:162:in `process'
from sidekiq/processor.rb:78:in `process_one'
from sidekiq/processor.rb:68:in `run'
from sidekiq/util.rb:15:in `watchdog'
from sidekiq/util.rb:24:in `block in safe_thread'
I have even taken out the entire 'perform' block of code i.e. the worker does nothing to confirm I don't have some sort of regressive call etc. I confirm that my other workers fire and process just fine. Checked for obvious typos - banging my head against the wall at this point.
UPDATE
Ok - I have confirmed one thing - if I add any new workers with any name this triggers the same error. I even rebooted the entire production server to confirm the whole code was reloaded etc.
It ended up being Redis (or at least my fix was related). Found this post:
https://github.com/mperham/sidekiq/issues/2834#issuecomment-184800981
and it was a Redis namespace conflict. My server does have elasticsearch running also so that makes sense. I am not sure why the old workers run but the new ones failed. My fix looks like this:
config.redis = {
url: ENV['REDIS_URL'],
namespace: "some_namespace_different_for_each_app"
}
You also need the redis-namespace gem BTW
In rails console..
Physician.find(1285849521) results in
ArgumentError: wrong number of arguments (1 for 0)
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `initialize'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `new'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `substitute_at'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:989:in `block in create_binds'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:987:in `each'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:987:in `each_with_index'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:987:in `create_binds'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:962:in `build_where'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:586:in `where!'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/relation/query_methods.rb:576:in `where'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/querying.rb:10:in `where'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/core.rb:150:in `block (2 levels) in find'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/statement_cache.rb:80:in `call'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/statement_cache.rb:80:in `create'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activerecord-4.2.0.beta4/lib/active_record/core.rb:149:in `block in find'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/2.1.0/mutex_m.rb:73:in `synchronize'
... 13 levels...
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:246:in `load'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:246:in `block in load'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:237:in `load_dependency'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activesupport-4.2.0.beta4/lib/active_support/dependencies.rb:246:in `load'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/commands/rails.rb:6:in `call'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/command_wrapper.rb:38:in `call'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:180:in `block in serve'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:153:in `fork'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:153:in `serve'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:128:in `block in run'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:122:in `loop'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application.rb:122:in `run'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/spring-1.1.3/lib/spring/application/boot.rb:18:in `<top (required)>'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Users/tim/.rbenv/versions/2.1.5/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
and of course..
Physician.find() results in "ActiveRecord::RecordNotFound: Couldn't find Physician without an ID"
My physician.rb is
class Physician < ActiveRecord::Base
self.table_name = "t_phys"
self.primary_key = "sln"
end
I'm using a legacy postgres db, the table t_phys has a natural key called sln, which is a 10 digit integer. There is a physician in the db with sln 1285849521 (the integer in the find method above), which I know because Physician.all() works properly and that's the first record that is displayed.
What am I doing wrong? How can I get the find method to work properly? I'm just getting started with rails again, probably a newbie mistake somewhere. Appreciate the help!
For more detail, when I got to localhost:3000/physicians/1285849521, the page renders:
ArgumentError in PhysiciansController#show
Wrong number of arguments (1 for 0)
Extracted source (around line #160):
159 def substitute_at(column, index)
160 Arel::Nodes::BindParam.new "$#{index + 1}"
161 end
162
163 def exec_query(sql, name = 'SQL', binds = [])
I can provide the full stack trace if necessary.
Seems like it should work, but I'm wondering if the custom primary key is still messing with find.
Maybe this background will help confirm one way or the other:
http://ruby-journal.com/how-to-override-default-primary-key-id-in-rails/
Thanks to Todd Agulnick's comment above, I updated to Rails 4.2 rc2 and the error went away. I encountered a new error, which I resolved and is outside the scope of this question. Thanks Todd!
I am using Mongoid and delayed_job_mongoid gems. Everything is in its latest version, including Rails (3.2.3).
I understand that if I put handle_asynchronously after any method declaration, this method will always be run async. But I get undefined method error like this:
class Item
# mongoid include stuff
def shout
puts 'a simple hi'
end
handle_asynchronously :shout
end
item = Item.create
item.shout # returns a delayed job object
j = _
# wait a moment
j.last_error
{undefined method `shout_without_delay' for #<Item:0x007f8365e62978>
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/mongoid-2.4.9/lib/mongoid/attributes.rb:166:in `method_missing'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/performable_method.rb:26:in `perform'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/backend/base.rb:94:in `block in invoke_job'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/lifecycle.rb:60:in `call'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/lifecycle.rb:60:in `block in initialize'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/lifecycle.rb:65:in `call'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/lifecycle.rb:65:in `execute'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/lifecycle.rb:38:in `run_callbacks'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/backend/base.rb:91:in `invoke_job'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/worker.rb:178:in `block (2 levels) in run'
/Users/nik/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/timeout.rb:68:in `timeout'
/Users/nik/.rvm/gems/ruby-1.9.3-p194/gems/delayed_job-3.0.2/lib/delayed/worker.rb:178:in `block in run'
/Users/nik/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
BUT if I had called
item.delay.shout
without the handle_asynchronously line
it will work!
Any ideas?
THANKS!
this is the author of the post. I found out what happened. Short answer: You have to restart the workers in the terminal
[control + c]
rake jobs:work
for mongoid delay jobs to be able to find the method. I do not know why. So just remember to restart the workers whenever you have added another line of handle_asynchronously :method
Happy coding!
You syntax should be
class Item
# mongoid include stuff
def shout
puts 'a simple hi'
end
handle_asynchronously :shout
end
you can get more details from here https://github.com/collectiveidea/delayed_job
I am trying to use DelayedJob and the job is failing, giving the following error in the database:
{Delayed::DeserializationError
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/serialization/active_record.rb:7:in `yaml_new'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/yaml.rb:133:in `transfer'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/yaml.rb:133:in `node_import'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/yaml.rb:133:in `load'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/yaml.rb:133:in `load'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/backend/base.rb:79:in `payload_object'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/backend/base.rb:87:in `invoke_job_without_newrelic_transaction_trace'
(eval):3:in `invoke_job'
/Library/Ruby/Gems/1.8/gems/newrelic_rpm-2.13.4/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:252:in `perform_action_with_newrelic_trace'
/Library/Ruby/Gems/1.8/gems/newrelic_rpm-2.13.4/lib/new_relic/agent/method_tracer.rb:141:in `trace_execution_scoped'
/Library/Ruby/Gems/1.8/gems/newrelic_rpm-2.13.4/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:247:in `perform_action_with_newrelic_trace'
(eval):2:in `invoke_job'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:120:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/timeout.rb:62:in `timeout'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:120:in `run'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:119:in `run'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:177:in `reserve_and_run_one_job'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:104:in `work_off'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:103:in `times'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:103:in `work_off'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:78:in `start'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:77:in `start'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:74:in `loop'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/worker.rb:74:in `start'
/Library/Ruby/Gems/1.8/gems/delayed_job-2.1.3/lib/delayed/tasks.rb:9
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Library/Ruby/Gems/1.8/gems/rake-0.8.7/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
Not sure where to start in diagnosing this. This has never happened before and I have used delayed job before to serialize model objects without any issues. Why this time?
Thanks in advance!
It's not really a deserialization error, it's an ActiveRecord record-not-found error on a simple Model.find(id) query.
If you want to know the details, log them in the delayed_job-2.1.3/lib/delayed/serialization/active_record.rb file, in the rescue statement, just before delayed-job stupidly raises the DeserializationError and throws the useful information away.
Michiel is right. Look at your handler field for objects like "!ruby/ActiveRecord:YourClassName"
Then check if objects can be retrieved via the primary key
From the console you can also test this out by doing something like:
# first job in your delayed queue
YAML.load(Delayed::Backend::ActiveRecord::Job.first.handler)
I believe this occurs when you run a job against an unsaved or deleted AR object since the deserialization for AR loads the record by id. An exception should probably be thrown if you attempt to delay a method on an unsaved AR object.
There's also a documented bug with DJ when the params passed into the handler field in the DB are longer than a standard TEXT column:
https://github.com/collectiveidea/delayed_job/issues/491
If this happens to be your problem, changing the column to a MEDIUMINT should fix the issue.
I did this in a migration like so:
change_column :delayed_jobs, :handler, :text, :limit => 16777215
ActiveRecord::Base.connection.execute("DELETE FROM delayed_jobs WHERE LENGTH(handler) >= 65535")
You can check to see if it's an issue with a simple DB query:
SELECT * FROM delayed_jobs WHERE LENGTH(handler) >= 65535
If anyone wants to make delayed_job just finish the job as a no-op you can monkey patch with this code in the initializer:
https://gist.github.com/spilliton/8494752
Today, I also suffered through this error and after doing hectic analysis found:
delayed_job converts methods & parameters to YAML format and stores it into database
It can be found using select * from delayed_jobs;
deserialization error occurs when delayed_job is not able to deserialize it.
Probable causes can be:
args["xyz"] used before calling delayed_job & inside worker using it as args[:xyz]
Sometimes extra arguments passed along with object to delayed_job that time delayed_job fails to build object as it is indifferent access.
I Hope this will help!
Sometimes when we upgrade libs delayed jobs still keep old references.
Try to find the id of delayed_job in logs and play to parse its handler to ruby to find the wrong reference
j = DelayedJob.find(XXX)
data = YAML.load_dj(j.handler)
data.to_ruby
I made a pull request to help with this problem.
Meanwhile you can use this lines
# config/initializers/delayed_job.rb
# Monkey patch to use old class references
module Psych
class << self; attr_accessor :old_class_references end
#old_class_references = {}
class ClassLoader
private
def find klassname
klassname = ::Psych.old_class_references[klassname] || klassname
#cache[klassname] ||= resolve(klassname)
end
end
module Visitors
class ToRuby < Psych::Visitors::Visitor
def revive klass, node
if klass.is_a? String
klassname = ::Psych.old_class_references[klass] || klass
klass = Kernel.const_get(klassname) rescue klassname
end
s = register(node, klass.allocate)
init_with(s, revive_hash({}, node), node)
end
end
end
end
# Add all old dependencies (hash keys) pointing to new references (hash values)
Psych.old_class_references = {
'ActiveRecord::AttributeSet' => 'ActiveModel::AttributeSet'
# ...
}
I'm trying to upgrade from 2.3.8 to 3.0.1, but this problem has been plaguing me and preventing further progress for quite some time now. Any attempt to create something from my models (calling Subject.create! from the console, for example) always results in this error:
NoMethodError: undefined method `name' for 0:Fixnum
from /.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/engines/sql/engine.rb:26:in `block in create'
from /.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/engines/sql/engine.rb:26:in `each'
from /.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/engines/sql/engine.rb:26:in `detect'
from /.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/engines/sql/engine.rb:26:in `create'
from /.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/algebra/relations/writes.rb:24:in `call'
from /.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/session.rb:17:in `create'
from /.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/algebra/relations/relation.rb:159:in `insert'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/relation.rb:14:in `insert'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/persistence.rb:271:in `create'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/timestamp.rb:47:in `create'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/callbacks.rb:281:in `block in create'
from /.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.1/lib/active_support/callbacks.rb:413:in `_run_create_callbacks'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/callbacks.rb:281:in `create'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/persistence.rb:247:in `create_or_update'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/callbacks.rb:277:in `block in create_or_update'
from /.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.1/lib/active_support/callbacks.rb:413:in `_run_save_callbacks'
... 1 levels...
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/persistence.rb:56:in `save!'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/validations.rb:49:in `save!'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/attribute_methods/dirty.rb:30:in `save!'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/transactions.rb:242:in `block in save!'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/transactions.rb:289:in `block in with_transaction_returning_status'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/connection_adapters/abstract/database_statements.rb:139:in `transaction'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/transactions.rb:204:in `transaction'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/transactions.rb:287:in `with_transaction_returning_status'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/transactions.rb:242:in `save!'
from /.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.1/lib/active_record/validations.rb:34:in `create!'
from (irb):1
from /.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/commands/console.rb:44:in `start'
from /.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/commands/console.rb:8:in `start'
from /.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.1/lib/rails/commands.rb:23:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'ruby-1.9.2-p0
It would appear Arel is not getting a proper relation to work with, but I am lost as to what is causing this. Any ideas?
Thanks!
Ryan
What version of Ruby are you using? It should be either 1.8.7 or 1.9.2. I've had similar inexplicable issues with 1.9.1.
I would recommend putting some debug statements inside arel. Edit the engine.rb in the last line of the stack trace. I think you will have to restart the console (not just reload!) to see the changes in the arel file.
Here is the offending line in engine.rb:
attribute = relation.record.detect { |attr, _| attr.name.to_s == relation.primary_key.to_s }
Maybe try printing out the attr names and see if anything is passing thru the array detect method. Or print out the class of the "attr". The class should be "Arel::Attribute", but obviously a Fixnum is passing in there somehow.
attribute = relation.record.detect do |attr, _|
p attr.class
p attr.name
attr.name.to_s == relation.primary_key.to_s
end
Just a guess but I am thinking maybe a plugin/gem is interfering with something in your models. Are you using any dependencies that tie directly into ActiveRecord?
Another good exercise would be to create a blank Rails 3 app (with no gems or plugin dependencies) with one model and see if you get the same errors. That would rule out something in your development environment. Then if that works, then maybe you can start removing some of the dependencies one by one from the other app and see if one of them is causing the error.