This appears to be caused by the last captured hold check in the new open-ils.storage.action.live_holds.wide_hash method. This method was introduced in Evergreen 3.2, so 3.1 should not be affected by this bug.
This code check attempts to find the most recently captured hold for the copy, but it fails if there are uncaptured holds that have the same current hold copy as the one being checked in. My experimentation on PostgreSQL 9.5 shows that these holds with a NULL capture_time sort before the holds with a capture_time in the below query:
SELECT id
FROM action.hold_request recheck
WHERE recheck.current_copy = cp.id
ORDER BY capture_time DESC
LIMIT 1
Thus returning a different hold from the one being put on the shelf. This id mismatch prevents the hold data from being returned to the client. This causes the hold not to show up in the holds shelf list.
The query above needs to have "AND capture_time IS NOT NULL" added to the WHERE clause. Branch forthcoming.
This appears to be caused by the last captured hold check in the new open-ils. storage. action. live_holds. wide_hash method. This method was introduced in Evergreen 3.2, so 3.1 should not be affected by this bug.
This code check attempts to find the most recently captured hold for the copy, but it fails if there are uncaptured holds that have the same current hold copy as the one being checked in. My experimentation on PostgreSQL 9.5 shows that these holds with a NULL capture_time sort before the holds with a capture_time in the below query:
SELECT id current_ copy = cp.id
FROM action.hold_request recheck
WHERE recheck.
ORDER BY capture_time DESC
LIMIT 1
Thus returning a different hold from the one being put on the shelf. This id mismatch prevents the hold data from being returned to the client. This causes the hold not to show up in the holds shelf list.
The query above needs to have "AND capture_time IS NOT NULL" added to the WHERE clause. Branch forthcoming.