hold queue positions not starting at 1

Bug #1164132 reported by Jason Etheridge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned
2.2
Won't Fix
Undecided
Unassigned
2.3
Fix Released
Undecided
Unassigned

Bug Description

This can happen when there are no potential copies to fulfill the holds. There's a secondary call to find similar holds to build the "queue" from, and it does not consider whether those holds are cancelled or not.

Revision history for this message
Bill Erickson (berick) wrote :

Fix pushed to working => user/berick/lp1164132-hold-queue-ignore-canceled

tags: added: holds pullrequest
Changed in evergreen:
milestone: none → 2.4.0-rc
Revision history for this message
Jason Etheridge (phasefx) wrote :

For a test, I took stock master and the stock test data, and then... noticed that hold with id = 1 has 0 potential copies and the bib that it is targeting has no other holds; so before changing any data or code, for reference:

srfsh# request open-ils.circ open-ils.circ.hold.queue_stats.retrieve "d69b0fb71e025dd509bdc13963da974b" 1

Received Data: {
  "potential_copies":0,
  "status":1,
  "total_holds":1,
  "queue_position":1,
  "estimated_wait":-1
}

Then I made a near duplicate yet cancelled hold:
evergreen2=# insert into action.hold_request (cancel_time, cancel_cause, target, request_lib, requestor, usr, selection_ou, pickup_lib, hold_type) select now(), 5, target, request_lib, requestor, usr, selection_ou, pickup_lib, hold_type from action.hold_request where id = 1;
UPDATE 1

And that incorrectly changed the total_holds reported, but not the queue_position:
srfsh# request open-ils.circ open-ils.circ.hold.queue_stats.retrieve "d69b0fb71e025dd509bdc13963da974b" 1

Received Data: {
  "potential_copies":0,
  "status":1,
  "total_holds":2,
  "queue_position":1,
  "estimated_wait":-1
}

So I changed the request_time on the hold I just created to something before its peer hold:
evergreen2=# update action.hold_request set request_time = (select min(request_time) from action.hold_request) - '1 month'::interval where id = (select max(id) from action.hold_request);
UPDATE 1

And that did the trick:
srfsh# request open-ils.circ open-ils.circ.hold.queue_stats.retrieve "d69b0fb71e025dd509bdc13963da974b" 1

Received Data: {
  "potential_copies":0,
  "status":1,
  "total_holds":2,
  "queue_position":2,
  "estimated_wait":-1
}

And then I put in Bill's patch and restarted services:
srfsh# request open-ils.circ open-ils.circ.hold.queue_stats.retrieve "d69b0fb71e025dd509bdc13963da974b" 1

Received Data: {
  "potential_copies":0,
  "status":1,
  "total_holds":1,
  "queue_position":1,
  "estimated_wait":-1
}

Signed off at collab/phasefx/lp1164132-hold-queue-ignore-canceled and pushed to master. I don't have the big picture anymore for the other branches and how they're maintained

Revision history for this message
Ben Shum (bshum) wrote :

Setting to fix committed for master/2.4, but then assigning to 2.2 and 2.3 release maintainers for backport consideration.

Changed in evergreen:
status: New → Fix Committed
Ben Shum (bshum)
Changed in evergreen:
status: Fix Committed → Fix Released
Revision history for this message
Ben Shum (bshum) wrote :

Marking as "won't fix" for 2.2 because we are outside the 2.2 support timeframe for non-security bug fixes.

Revision history for this message
Bill Erickson (berick) wrote :

Pulled into rel_2_3. Thanks, Jason.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.