New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
self is a hash in after_initialize active record callback #2244
Comments
Please give the full backtrace.
|
|
This appears to be a bug but I can also tell the code is breaking Rule #1 by serializing the entire User object, triggering this behavior: https://github.com/mperham/sidekiq/wiki/Best-Practices#1-make-your-job-parameters-small-and-simple |
Hm, that is strange, i don't think we serialize the entire user object. We normally do stuff like user.delay.xyz. I would assume that this only stores the user id and gets the user object freshly from the db once the job runs? |
Thanks! |
Nope, it serializes the instance too. I don't recommend using |
Ah, okay, thanks for the hint! |
Wondering if it could not be changed to only serialize id and type and reload freshly from the db when running the job? |
My policy (contrary to ActiveJob) is that Sidekiq code does not touch the database, since you might want to control transaction boundaries, use special connection handling, rescue errors, etc. |
Ah, okay, makes sense, we could write our own wrapper for this. |
@seuros globalid looks useful, yes |
Trying to open dead jobs in the sidekiq interface gives me an error:
Sidekiq tries to initialize the user object as hash for some reason and not as an actual user object, so attribute assignment in the initalization callback fails...
The text was updated successfully, but these errors were encountered: