[Bug 28205] New: Less important hold trapped before or no hold trapped in some cases (race condition)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28205 Bug ID: 28205 Summary: Less important hold trapped before or no hold trapped in some cases (race condition) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: joonas.kylmala@helsinki.fi QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com So our libraries ran into a strange hold problem which turned out to be a race condition: if you change priority of holds and return an item and build_holds_queue.pl cron is not yet run again the priority is not updated and you fill hold with less importance! After build_holds_queue.pl the priorities are OK because hold_fill_targets gets updated according to the right hold priority. Similar race condition also happens when you have already some items for the biblio in hold_fill_targets and add a new item to the biblio and try to return it it doesn't attach to any waiting holds until the build_holds_queue.pl is ran. To better understand the issue I think it is easier to look the code in C4::Reserves::_Findgroupreserve(). Explaining with words is bit difficult... Basically in that function the SQL selects
my $title_level_target_query = qq{
my $query = qq{
should be UNION'ed to fix the case when adding new item which could potentially fill the hold. This might cause unoptimal logistic route to be used but still would follow the hold priority. To fix the issue of changing hold priorities we need to update hold_fill_targets table by calling C4::HoldsQueue::CreateQueue() every time staff member updates hold priorities in a biblio. But even with these improvements wouldn't this be buggy when deleting items from the biblio record? Not sure how to solve that case. Added major bug priority for this but if you feel like it doesn't deserve it feel free to change to normal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28205 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28205 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=34666, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=29346 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28205 Nick G <n.gagnon@dover.nh.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |n.gagnon@dover.nh.gov --- Comment #1 from Nick G <n.gagnon@dover.nh.gov> --- Hello! We have been running into this problem as well. Patron holds are not loading correctly after changing the status of the hold. For instance if we revert a hold and check-in the item to populate the next hold account, the previous account still shows. This occurs still days later in some cases although sometimes this will take just a couple minutes to register as a change. The workarounds we have seen are not efficient for staff (suspend hold- check in item- go back to patron account- unsuspend hold- reorder hold list). Thank you, -Nick -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org