Has anyone faced this issue: # example code def member_logged_in(*args) binding.pry @member = Member.find(args[0]) @club = Club.find(@member.club_id]) mail(:to =>.....) end Under 'rails console', I can 'find' a member from the console prompt => @member.club_id returns a value. When the same code is invoked via worker in Sidekiq, from the pry prompt, @member.club_id returns nil. Thoughts?
It's possible this is a race condition with your ActiveRecord transactions. If you are creating a job in an after_save (or after_create/update) callback, it's possible that sidekiq is starting the job before the database transaction is committed. Since the sidekiq doesn't see the DB change inside the job creator's transaction, the record isn't there (yet). There's a longer explanation and a solution here... http://rails-bestpractices.com/posts/695-use-after_commit Hope that helps.
Yep, we see this all the time at The Clymb. The answer is to use either after_commit or delay_for(5.seconds). On Thu, Jul 26, 2012 at 8:19 AM, Darren Boyd <dboyd@realgravity.com> wrote: > > It's possible this is a race condition with your ActiveRecord transactions. > > If you are creating a job in an after_save (or after_create/update) > callback, it's possible that sidekiq is starting the job before the database > transaction is committed. Since the sidekiq doesn't see the DB change inside > the job creator's transaction, the record isn't there (yet). > > There's a longer explanation and a solution here... > http://rails-bestpractices.com/posts/695-use-after_commit > > Hope that helps. >
I'm not doing any database updates/inserts when creating the email, so I don't think it's a transaction issue. And, unfortunately delay_for(...) did't work. Back to the drawing board :( On Thu, Jul 26, 2012 at 11:39 AM, Mike Perham <mperham@gmail.com> wrote: > Yep, we see this all the time at The Clymb. The answer is to use > either after_commit or delay_for(5.seconds). > > On Thu, Jul 26, 2012 at 8:19 AM, Darren Boyd <dboyd@realgravity.com> > wrote: > > > > It's possible this is a race condition with your ActiveRecord > transactions. > > > > If you are creating a job in an after_save (or after_create/update) > > callback, it's possible that sidekiq is starting the job before the > database > > transaction is committed. Since the sidekiq doesn't see the DB change > inside > > the job creator's transaction, the record isn't there (yet). > > > > There's a longer explanation and a solution here... > > http://rails-bestpractices.com/posts/695-use-after_commit > > > > Hope that helps. > > >
I think I have a break in this case... What was making this even more confusing is that the problem is occurring on my workstation (Ubuntu 12.04). I installed this on my server just to test this out and there, it works! The server is Ubuntu 10.04. What I noticed is that in the start up line on my workstation (the problem machine), Sidekiq logs that it is using Ruby 1.9.3-p0, which makes little sense since I am using 1.9.3-p194 and have it set as the global version via rbenv. The Ruby version logged by the instance on the (working) server displays the correct version of Ruby. At least I have something to investigate. On Thu, Jul 26, 2012 at 8:53 PM, Joe Meirow <joe.meirow@gmail.com> wrote: > I'm not doing any database updates/inserts when creating the email, so I > don't think it's a transaction issue. And, unfortunately delay_for(...) > did't work. Back to the drawing board :( > > > > On Thu, Jul 26, 2012 at 11:39 AM, Mike Perham <mperham@gmail.com> wrote: > >> Yep, we see this all the time at The Clymb. The answer is to use >> either after_commit or delay_for(5.seconds). >> >> On Thu, Jul 26, 2012 at 8:19 AM, Darren Boyd <dboyd@realgravity.com> >> wrote: >> > >> > It's possible this is a race condition with your ActiveRecord >> transactions. >> > >> > If you are creating a job in an after_save (or after_create/update) >> > callback, it's possible that sidekiq is starting the job before the >> database >> > transaction is committed. Since the sidekiq doesn't see the DB change >> inside >> > the job creator's transaction, the record isn't there (yet). >> > >> > There's a longer explanation and a solution here... >> > http://rails-bestpractices.com/posts/695-use-after_commit >> > >> > Hope that helps. >> > >> > >
Which is really amazing since 1.9.3-p0 is not installed on my system. On Thu, Jul 26, 2012 at 6:08 AM, Joe Meirow <joe.meirow@gmail.com> wrote: > > > > Has anyone faced this issue: > > # example code > def member_logged_in(*args) > binding.pry > @member = Member.find(args[0]) > @club = Club.find(@member.club_id]) > mail(:to =>.....) > end > > > Under 'rails console', I can 'find' a member from the console prompt => > @member.club_id returns a value. > > When the same code is invoked via worker in Sidekiq, from the pry prompt, > @member.club_id returns nil. > > Thoughts? >