[Koha-bugs] [Bug 33287] Race condition in Koha::BackgroundJob?

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Tue Mar 21 16:30:59 CET 2023


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33287

--- Comment #5 from Nick Clemens <nick at bywatersolutions.com> ---
(In reply to Janusz Kaczmarek from comment #4)
> (In reply to Nick Clemens from comment #3)
> > It may also be this one then:
> > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33019
> > 
> > It's another race condition due to the transaction
> 
> Thank you for this hint.  However, it seems that the case reported and
> patched by Aleisha is still only the tip of the iceberg.  It seems to me
> that not only creation a new record causes this issue.  Our findings of
> today are that it happens (i.e. "No job found for id=nnn" in
> worker-output.log) also when for instance a user renews his checkouts.
> 
> What if, in background_jobs_worker.pl, we waited like 500 ms (100 ms?)
> before calling Koha::BackgroundJobs->find ?
> 
> Or maybe, in Koha::BackgroundJob::enqueue, calling in loop ->in_storage
> after ->store would give us green light to proceed further to call
> $conn->send_with_receipt ?

I don't like the idea of a delay built in - I think we need to prevent the race
condition if we can.

It looks like this is the same issue - AddRenewal is called in a transaction -
so we need to index after the transaction is committed. Could you open a new
bug for that one?

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.


More information about the Koha-bugs mailing list