Incorrect copy status caused by reshelving process colliding with item checkout

Bug #1018011 reported by Bill Erickson on 2012-06-26
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

Evergreen 2.1+

In a busy production system with a large database, the reshelving-complete script can take several minutes to run. This can lead to the following scenario:

copy checked in -> status 7
copy picked up for processing by the reshelving-complete process
copy checked out -> status 1
reshelving-complete process completes -> status 0.

This results in an open circulation on a copy with a status of 0, which apart from just being wrong, prevents renewals of the circulation due to bad copy status.

The occurrence increases the more often the reshelving-complete process is run. For example, running it hourly in a busy system creates many (relatively speaking) opportunities for this to happen.

Ben Shum (bshum) wrote :

Confirmed to occur in our 2.2 systems. Just had a case reported today, but there may be others lurking.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → 2.2.1
Changed in evergreen:
milestone: 2.2.1 → 2.2.2
Ben Shum (bshum) on 2012-12-21
no longer affects: evergreen/2.1
Ben Shum (bshum) on 2013-03-17
no longer affects: evergreen/master
Changed in evergreen:
milestone: 2.4.0-beta → 2.4.0-rc
Ben Shum (bshum) on 2013-04-27
Changed in evergreen:
milestone: 2.4.0-rc → none
Ben Shum (bshum) on 2013-08-22
no longer affects: evergreen/2.2
Tim Spindler (tspindler-cwmars) wrote :

It appears we may be seeing this in 2.4.3 version of our system

Bill Erickson (berick) on 2014-10-14
no longer affects: evergreen/2.4
no longer affects: evergreen/2.3
Blake GH (bmagic) wrote :

I found that this query identifies the situation:

select "all",barcode from
(select string_agg(status::text,',' order by audit_id) as "all",barcode from
auditor.asset_copy_history group by barcode)
 as aach
 where "all" ~ '7,1,0'

Finding items that went from re-shelving to checked out to available

Blake GH (bmagic) wrote :

Confirmed in 2.6.1

Thomas Berezansky (tsbere) wrote :

This branch *might* be a suitable fix for this issue. But I don't know how to test it given the nature of the issue itself. As such I am not adding a pullrequest for it, though if someone else comes up with a testing plan feel free.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/lp1018011

no longer affects: evergreen/2.5
no longer affects: evergreen/2.6
no longer affects: evergreen/2.7
Blake GH (bmagic) wrote :

We have been using this branch in production for 3 years, it's working just fine. Thanks Thomas!

tags: added: pullrequest
Andrea Neiman (aneiman) wrote :

Given that this branch is nearly 5 years old, was written for (presumably) 2.6, and was not pullrequested by the original author -- I'm removing the pullrequest tag. Blake or anyone else who is using it in production and/or has testing, obviously feel free to post an updated branch for review.

tags: removed: pullrequest
Elaine Hardy (ehardy) on 2019-03-07
tags: added: checkout
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers