It is an irony that this might not be reproducible always in the production server.
If the sidekiq is slow enough, this might not happen always as the request might have already finished and the transaction is committed to DB.
We have faced a similar issue related to sidekiq. We queued a job to sidekiq with the model primary key. inside sidekiq we will fetch from DB using PK and we will do the heavy operation (We don't want to push the entire object to sidekiq as it was costly in our case). Sometimes we delete the record even before it is getting processed by sidekiq. during this operation, it started throwing null pointer exception.
adding one more thing to your issue,
If the database is set to 'Read Uncommitted', you might not face the same issue. But most of the system won't have that transaction isolation setting as it is the lowest of all isolation level and has a lot of problems in the real-world application.
I'm a husband, dad, and rails dev who builds things to help businesses from the bootstrapper on up. Helping recover your business failed payments with Overdue.io.
Yeah sidekiq is surprisingly fast. I was regularly running into the issue although it wasn’t actually an issue. Just delayed an email an extra 30 seconds or so. On my service I send all sorts of things directly to sidekiq. Most of which are webhooks so they’re not huge. I’m going to start adding more analytics so I’ll either just continue to listen to a bunch of webhooks or ping the API every hour or so to update the metrics for my customers. Both of which I’ll have sidekiq handle. As with the database and reading uncommitted things the only issue I was having was with new users being added. We’ll see as the load increases whether that sort of issue appears again.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It is an irony that this might not be reproducible always in the production server.
If the sidekiq is slow enough, this might not happen always as the request might have already finished and the transaction is committed to DB.
We have faced a similar issue related to sidekiq. We queued a job to sidekiq with the model primary key. inside sidekiq we will fetch from DB using PK and we will do the heavy operation (We don't want to push the entire object to sidekiq as it was costly in our case). Sometimes we delete the record even before it is getting processed by sidekiq. during this operation, it started throwing null pointer exception.
adding one more thing to your issue,
If the database is set to 'Read Uncommitted', you might not face the same issue. But most of the system won't have that transaction isolation setting as it is the lowest of all isolation level and has a lot of problems in the real-world application.
Yeah sidekiq is surprisingly fast. I was regularly running into the issue although it wasn’t actually an issue. Just delayed an email an extra 30 seconds or so. On my service I send all sorts of things directly to sidekiq. Most of which are webhooks so they’re not huge. I’m going to start adding more analytics so I’ll either just continue to listen to a bunch of webhooks or ping the API every hour or so to update the metrics for my customers. Both of which I’ll have sidekiq handle. As with the database and reading uncommitted things the only issue I was having was with new users being added. We’ll see as the load increases whether that sort of issue appears again.