opportunistic capture can fail to find relevant holds

[Galen Charlton]

The list of potential holds that an item might fill returned by open-ils.storage.action.hold_request.nearest_hold can contain duplicates entries. The duplicates occur for each non-blocking standing penalty after the first for the patron associated with a candidate hold - and the notes consolidation change likely means that there are more of them.

As a consequence, opportunistic hold capture can end up doing redundant hold permit tests, thereby wasting some of the up to 100 candidate holds returned by the nearest_hold method. Empirically, this has resulted in opportunistic hold capture failing to target holds that could have been filled (for a really popular title).

Evergreen 3.9

[Galen Charlton (gmc)]

An initial patch for feedback is available in the user/gmcharlt/lp2004520_dedupe_nearest_hold-wip working branch.

[Terran McCanna (tmccanna)]

Adding pullrequest tag in hopes that this will get more eyes on it for testing

[Galen Charlton (gmc)]

We're working on a reworked version of the patch, so while more eyes are always appreciated for the concept, the current WIP should _not_ be merged.

[Chris Sharp (chrissharp123)]

Removing pullrequest tag per Galen's comment.

[Terran McCanna (tmccanna)]

Galen, has there been any progress on this? We're seeing some weirdness with some records that have a lot of holds and a lot of notes that seems like it could potentially be caused by this bug, but I'm not 100% sure.

[Galen Charlton (gmc)]

Yes - I need to blow some dust off a branch.

[Terran McCanna (tmccanna)]

We've confirmed that this is the bug that is causing the problem we are running into.

[Terran McCanna (tmccanna)]

FWIW, we've tested the patch as is and it solves our current problem.