fix: adds sync execution support#101
Conversation
|
In the case of |
@lionelchauvin i see what you mean, and i do agree. however, i don't see any way to tell if it's being called in a sync or async context within this module (e.g. given ideally it would be better if that LOC in sidekiq was which they do use elsewhere https://github.com/sidekiq/sidekiq/blob/c4c92b6be5908c9062734c594431a5f8708a3b8c/lib/sidekiq/testing.rb#L288 regardless, i'm happy to change how this is being checked if you have any ideas on how I could explicitly check for something like ** EDIT i don't think the |
|
you are right, Why not assign Thread.current[:batch] instead of use an instance variable ? If it is inline/sync there should be only one batch at the time in the current thread no ? ** EDIT |
PR to address #94
It seems that in synchronous execution with
perform_sync(an alias ofperform_inline), sidekiq is attempting to set thejob.bidlike so https://github.com/sidekiq/sidekiq/blob/96f867cb58b7fa0a6a832af1a732a339aa0eb61f/lib/sidekiq/job.rb#L236, and sidekiq-batch's worker extension does respond_to :bid, but only as a reader.This PR adds the minimum viable code to support execution of synchronous jobs by having them also defined as atter_writer, and an instance var.
I did make the assumption that this gem needs to rely on the current thread's execution context first, then fallback to the instance var when applicable. Happy to restructure if need be