Error while trying to deserialize arguments: uninitialized constant GlobalID::Locator #101
Comments
|
I am seeing the same thing (only happened twice) with no obvious trigger. It started few days after we bumped to rails 4.2.8 from 4.2.7.1, which also updated globalID from 0.3.7 to 0.4.0 |
|
I've also seen this twice in the past weeks (with thousands of processed jobs), without a specific deploy I could pinpoint it to. The first time occurred shortly after upgrading from rails 4.2.8 to 5.0. I'm running ruby 2.3.3, sidekiq 4.2.10, and globalid 0.4.0. |
|
I have the same problem!
|
|
I experienced the same with the following:
|
|
I'am experiencing the same error. It happens very much at random and only on production at Heroku. My stack:
|
|
Same. I have the stacktrace if required. I'm using active-elastic-job instead of sidekiq. |
|
Just happened for me with sidekiq, here's the backtrace: |
GlobalID uses `autoload` for the class load. https://github.com/rails/globalid/blob/c08e9a0a20e7b040d0ec5c55612afae8b40f16f6/lib/global_id.rb#L3..L9 In a thread-based backend like Sidekiq, there is a possibility that autoload may occur simultaneously in multiple threads, and as a result, it is presumed that an error may be caused by contention of autoload. In order to avoid the above issue, explicitly loaded the class at startup. Maybe fixes rails/globalid#101
In a thread-based backend like Sidekiq, there is a possibility that autoload may occur simultaneously in multiple threads, and as a result, it is presumed that an error may be caused by contention of autoload. In order to avoid the above issue, eager load the constants on boot. Maybe fixes rails#101
In a thread-based backend like Sidekiq, there is a possibility that autoload may occur simultaneously in multiple threads, and as a result, it is presumed that an error may be caused by contention of autoload. In order to avoid the above issue, eager load the constants on boot. Maybe fixes rails#101
In a thread-based backend like Sidekiq, there is a possibility that autoload may occur simultaneously in multiple threads, and as a result, it is presumed that an error may be caused by contention of autoload. In order to avoid the above issue, eager load the constants on boot. Maybe fixes rails#101
In a thread-based backend like Sidekiq, there is a possibility that autoload may occur simultaneously in multiple threads, and as a result, it is presumed that an error may be caused by contention of autoload. In order to avoid the above issue, eager load the constants on boot. Maybe fixes rails#101
In a thread-based backend like Sidekiq, there is a possibility that autoload may occur simultaneously in multiple threads, and as a result, it is presumed that an error may be caused by contention of autoload. In order to avoid the above issue, eager load the constants on boot. Maybe fixes rails#101
In a thread-based backend like Sidekiq, there is a possibility that autoload may occur simultaneously in multiple threads, and as a result, it is presumed that an error may be caused by contention of autoload. In order to avoid the above issue, eager load the constants on boot. Maybe fixes rails#101
|
I noticed the issue is still present in the current 0.4.0 version of the Gem, this is the backtrace:
I've verified the version by
Does anybody have some ideas how to get around this? It seems to happen quite early after the restart of the worker (which happens directly after a deploy). |
|
It should be fixed now in 0.4.1 |
|
With version |
From @jwoertink on April 19, 2017 19:16
I don't get this error often, but sometimes I get
I'm not able to recreate this error locally, and out of 310 processed jobs, it's only shown up twice.
I'm using Sidekiq with ActiveJob on Rails 5.0.2 with ruby 2.4.1.
Here's the data from Sidekiq
Copied from original issue: rails/rails#28801
The text was updated successfully, but these errors were encountered: