Summary: | Race condition in Koha::BackgroundJob? | ||
---|---|---|---|
Product: | Koha | Reporter: | Janusz Kaczmarek <januszop> |
Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P3 | CC: | aleisha, dcook, nick |
Version: | 22.11 | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33309 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
Description
Janusz Kaczmarek
2023-03-20 20:19:23 UTC
This should be fixed in 22.11.05+ *** This bug has been marked as a duplicate of bug 30172 *** (In reply to Nick Clemens from comment #1) > This should be fixed in 22.11.05+ > > *** This bug has been marked as a duplicate of bug 30172 *** Nick, thank you for your reaction. I have seen the Bug 30172 and checked that it is applied in 22.11 before filing this bug report. Despite the fact that Bug 30172 is applied I am still experiencing this issue. What am I missing? 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 (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 ? (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? (In reply to Nick Clemens from comment #5) [...] > 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? OK, Bug 33309 created. |