after_commit callback #191
Comments
|
@crankharder Hi, we stumbled across the same problem and we came up with a simple after_commit queue. We have just extracted it into a gem https://github.com/shellycloud/after_commit_queue. |
|
+1. We stumbled onto the same issue as @crankharder (though we're using sidekiq instead of resque). @wijet, thanks for posting a workaround, I'll investigate it next. :) |
|
+1 Working good for me. |
|
+1 |
1 similar comment
|
+1 |
|
👍 Same problem using sidekiq and state_machine. |
|
+1 |
1 similar comment
|
👍 |
dzaporozhets
added a commit
to gitlabhq/gitlabhq
that referenced
this issue
Sep 25, 2015
Fix bug where projects would appear to be stuck in the forked import state A race condition existed between when Rails committed the `import_status` to `started` and when the Sidekiq worker forked a project. If this fork were quick, it's possible that the worker would attempt to move into the `finished` state before the `started` state took effect. As mentioned in https://github.com/mperham/sidekiq/wiki/Problems-and-Troubleshooting#cannot-find-modelname-with-id12345, we can either delay the worker to ensure the DB has a chance to update, or use the nice `after_commit_queue` gem to schedule the task after the state machine commit. See: * pluginaweek/state_machine#191 * https://github.com/shellycloud/after_commit_queue Closes #2736 See merge request !1434
dzaporozhets
added a commit
to gitlabhq/gitlabhq
that referenced
this issue
Sep 29, 2015
Fix bug where projects would appear to be stuck in the forked import state A race condition existed between when Rails committed the `import_status` to `started` and when the Sidekiq worker forked a project. If this fork were quick, it's possible that the worker would attempt to move into the `finished` state before the `started` state took effect. As mentioned in https://github.com/mperham/sidekiq/wiki/Problems-and-Troubleshooting#cannot-find-modelname-with-id12345, we can either delay the worker to ensure the DB has a chance to update, or use the nice `after_commit_queue` gem to schedule the task after the state machine commit. See: * pluginaweek/state_machine#191 * https://github.com/shellycloud/after_commit_queue Closes #2736 See merge request !1434
|
Thanks it works perfectly |
rymai
pushed a commit
to gitlabhq/gitlabhq
that referenced
this issue
Oct 10, 2016
Fix ci pipeline processing with async jobs ## What does this MR do? This MR fixes CI pipeline processing with asynchronous jobs called from `around_transition` provided by state machine. For details see pluginaweek/state_machine#191 and commit f68acba. ## Why was this MR needed? Recently merged https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6650 introduced problem with asynchronous job being deployed when `around_transition` still held transaction, which caused race condition that prevented pipeline status to change in a proper way. ## What are the relevant issue numbers? Closes #23111 See merge request !6736
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there any way to make the method defined by after_transition/do fire after the SQL commit has taken place?
I'm seeing race condition between state machine and resque. That is, if I drop an event in an after_transition, resque will pick up the job, and load the object before the initial transaction has been committed to the database - thus getting stale data.
If I dropped the event after the COMMIT has taken place, this would be a non-issue. Fixing this 'bug' on the resque side is hacky at best. I could lock, sleep, loop/repeat, meh, none of it looks good.
Thanks
The text was updated successfully, but these errors were encountered: