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
Related
By executing the whenever --update-crontab command, the following error returns:
/usr/lib/ruby/vendor_ruby/whenever/cron.rb:132:in `parse_as_string': Couldn't parse: 31557600 (ArgumentError)
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:112:in `parse_time'
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:50:in `time_in_cron_syntax'
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:42:in `output'
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:36:in `block (2 levels) in output'
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:35:in `each'
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:35:in `block in output'
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:34:in `each'
from /usr/lib/ruby/vendor_ruby/whenever/cron.rb:34:in `output'
from /usr/lib/ruby/vendor_ruby/whenever/job_list.rb:151:in `block (2 levels) in cron_jobs'
from /usr/lib/ruby/vendor_ruby/whenever/job_list.rb:147:in `each'
from /usr/lib/ruby/vendor_ruby/whenever/job_list.rb:147:in `block in cron_jobs'
from /usr/lib/ruby/vendor_ruby/whenever/job_list.rb:146:in `each'
from /usr/lib/ruby/vendor_ruby/whenever/job_list.rb:146:in `cron_jobs'
from /usr/lib/ruby/vendor_ruby/whenever/job_list.rb:65:in `generate_cron_output'
from /usr/lib/ruby/vendor_ruby/whenever.rb:10:in `cron'
from /usr/lib/ruby/vendor_ruby/whenever/command_line.rb:54:in `whenever_cron'
from /usr/lib/ruby/vendor_ruby/whenever/command_line.rb:106:in `updated_crontab'
from /usr/lib/ruby/vendor_ruby/whenever/command_line.rb:35:in `run'
from /usr/lib/ruby/vendor_ruby/whenever/command_line.rb:6:in `execute'
from /usr/bin/whenever:41:in `<main>'
My schedule.rb file:
every 1.year do
rake "maintenances:renew"
end
Any ideas?
If you're having problems with 1.year method, you can use the two following alternatives.
1 - Shortcuts
every :year do
rake "maintenances:renew"
end
2 - Expressions
every '0 0 1 12 *' do
rake "maintenances:renew"
end
If you want to learn more about these options, check the official documentation.
To test expressions, I recommend crontab.guru
I got a simple and free heroku app running where I added redis/sidekiq in order to send out mails in the background. I set everything up and once I start the worker, I get following error message in a loop:
Error fetching job: ERR max number of clients reached
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:114:in `call'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:95:in `block in connect'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:280:in `with_reconnect'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:93:in `connect'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:351:in `ensure_connected'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:208:in `block in process'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:293:in `logging'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:207:in `process'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:113:in `call'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:196:in `block in call_with_timeout'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:267:in `with_socket_timeout'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis/client.rb:195:in `call_with_timeout'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:1097:in `block in _bpop'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:57:in `block in synchronize'
/app/vendor/ruby-2.2.2/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:57:in `synchronize'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:1094:in `_bpop'
/app/vendor/bundle/ruby/2.2.0/gems/redis-3.2.2/lib/redis.rb:1139:in `brpop'
/app/vendor/bundle/ruby/2.2.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:393:in `call_with_namespace'
/app/vendor/bundle/ruby/2.2.0/gems/redis-namespace-1.5.2/lib/redis/namespace.rb:290:in `method_missing'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/fetch.rb:35:in `block in retrieve_work'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq.rb:84:in `block in redis'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:64:in `block (2 levels) in with'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:63:in `handle_interrupt'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:63:in `block in with'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:60:in `handle_interrupt'
/app/vendor/bundle/ruby/2.2.0/gems/connection_pool-2.2.0/lib/connection_pool.rb:60:in `with'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq.rb:81:in `redis'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/fetch.rb:35:in `retrieve_work'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:85:in `get_one'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:95:in `fetch'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:78:in `process_one'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/processor.rb:67:in `run'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/util.rb:16:in `watchdog'
/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.1/lib/sidekiq/util.rb:24:in `block in safe_thread'
sidekiq.yml:
---
:queues:
- default
- mailers
sidekiq.rb:
Sidekiq.configure_server do |config|
config.redis = { :namespace => "mynamespace" }
end
Sidekiq.configure_client do |config|
config.redis = { :namespace => "mynamespace" }
end
require "sidekiq/web"
Sidekiq::Web.app_url = "/"
Sidekiq::Web.use(Rack::Auth::Basic, "Application") do |username, password|
username == ENV.fetch("SIDEKIQ_WEB_USERNAME") &&
password == ENV.fetch("SIDEKIQ_WEB_PASSWORD")
end
Anyone an idea what's wrong here? If you need any further info on the config files or something, let me know.
Changing sidekiq.yml to
---
:queues:
- default
- mailers
:concurrency: 5
did the trick. Setting concurrency to 9 did not for some reason even though heroku allows 10 for the redis nano addon.
This was the best solution that I found. If you are using the free heroku plan and the free redis nano plan. All the connections have to add up to 10 or less. To make sure that the connections add up check out this blog post. http://manuelvanrijn.nl/blog/2012/11/13/sidekiq-on-heroku-with-redistogo-nano/
He explains how everything adds up.
The writer also has a calculator that will help to calculate what the configuration should be for your particular server, sidekiq etc. It also tells you where the information needs to be added.
I was stuck on this too hope it saves somebody some time :)
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'm not new to DynamoDB, but I'm new to DynamoID gem.
I can't achieve to make it work since I get the following error :
/aws-sdk-1.28.1/lib/aws/core/client.rb:366:in `return_or_raise': The action or operation requested is invalid. Verify that the action is typed correctly. (AWS::DynamoDB::Errors::InvalidAction)
/aws-sdk-1.28.1/lib/aws/core/client.rb:467:in `client_request'
(eval):3:in `list_tables'
/aws-sdk-1.28.1/lib/aws/dynamo_db/table_collection.rb:121:in `_each_item'
/aws-sdk-1.28.1/lib/aws/core/collection/with_limit_and_next_token.rb:54:in `_each_batch'
/aws-sdk-1.28.1/lib/aws/core/collection.rb:80:in `each_batch'
/aws-sdk-1.28.1/lib/aws/core/collection.rb:47:in `each'
/dynamoid-0.7.1/lib/dynamoid/adapter/aws_sdk.rb:185:in `collect'
/dynamoid-0.7.1/lib/dynamoid/adapter/aws_sdk.rb:185:in `list_tables'
/dynamoid-0.7.1/lib/dynamoid/adapter.rb:146:in `block (3 levels) in <module:Adapter>'
/dynamoid-0.7.1/lib/dynamoid/adapter.rb:39:in `benchmark'
/dynamoid-0.7.1/lib/dynamoid/adapter.rb:146:in `block (2 levels) in <module:Adapter>'
/dynamoid-0.7.1/lib/dynamoid/adapter.rb:25:in `block in reconnect!'
/dynamoid-0.7.1/lib/dynamoid/adapter.rb:39:in `benchmark'
/dynamoid-0.7.1/lib/dynamoid/adapter.rb:25:in `reconnect!'
/dynamoid-0.7.1/lib/dynamoid.rb:35:in `configure'
app/config/initializers/dynamoid.rb:1:in `<top (required)>'
It seems that list_tables doesn't exist, but it's a method of the AWS Ruby SDK
My model is very simple :
class Interaction
include Dynamoid::Document
table :name => :interactions, :key => :from, :read_capacity => 1, :write_capacity => 1
end
Could anybody help?
Cheers,
Emmanuel
I have an error that appears to be connected to these two links:
https://groups.google.com/forum/#!msg/mongoid/L6ESKP8QDpg/gmEyqejdAEEJ
https://github.com/mongoid/moped/pull/59
See console log below. I am running with Mongoid/MongoHQ, when I create an object (apparently any database object) I get this "need to login" error. Note however that the database object IS created and is in the database after the error.
Is there some way I can fix this myself, or perhaps it's something that MongoHQ needs to fix?
$ heroku run console
irb(main):004:0> Request.create!(:from_user => User.first, :to_user => User.first)
Moped::Errors::OperationFailure: The operation: #<Moped::Protocol::Command
#length=69
#request_id=7
#response_to=0
#op_code=2004
#flags=[]
#full_collection_name="admin.$cmd"
#skip=0
#limit=-1
#selector={:getlasterror=>1, :safe=>true}
#fields=nil>
failed with error "need to login"
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:74:in `block in command'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:521:in `[]'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:521:in `block (3 levels) in flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:520:in `map'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:520:in `block (2 levels) in flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:123:in `ensure_connected'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:516:in `block in flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:531:in `logging'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:515:in `flush'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:286:in `pipeline'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/session/context.rb:58:in `block in insert'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/session/context.rb:109:in `block in with_node'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/cluster.rb:150:in `block in with_primary'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/node.rb:168:in `ensure_primary'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/cluster.rb:149:in `with_primary'
from /app/vendor/bundle/ruby/1.9.1/gems/moped-1.2.0/lib/moped/session/context.rb:108:in `with_node'
... 13 levels...
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:405:in `__run_callback'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:385:in `_run_save_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:81:in `run_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/callbacks.rb:100:in `run_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence/insertion.rb:23:in `prepare'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence/operations/insert.rb:26:in `persist'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence.rb:50:in `insert'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence.rb:251:in `block in create!'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/threaded/lifecycle.rb:173:in `_creating'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.4/lib/mongoid/persistence.rb:249:in `create!'
from (irb):4
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/commands/console.rb:47:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/commands/console.rb:8:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/commands.rb:41:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'irb(main):005:0>
I am having the exact same problem. This is not exactly a solution but you can work around the problem by setting the 'safe' option in mongoid.yml to false. It would look similar to this:
production:
sessions:
default:
uri: <%= ENV['MONGOHQ_URL'] %>
options:
skip_version_check: true
safe: false
It turns out the problem is that MongoHQ upgraded their MongoDB and it introduced an incompatibility with mongoid's stable branch.
Chris Winslett fixed the bug and durran pulled it into mongoid master. But it was not included in the stable branch when I posted this stackoverflow.
Solutions:
I solved the problem by updating my gemfile to pull mongoid from github.
durran has now included it in stable-1.2.0 so you should get the fix if you gem update.