Long-frozen holds skew hold queue position calculation
Bug #1744341 reported by
Bill Erickson
This bug affects 5 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Medium
|
Unassigned | ||
3.11 |
Won't Fix
|
Medium
|
Unassigned | ||
3.12 |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Evergreen 3.0 / affects all versions
When a hold is frozen, its target state is locked into place until it is unfrozen and retargeted. Any copy maps that link to copies which are deleted or made otherwise unholdable over time will remain as long as the hold is frozen. This adds bulk to the hold copy map table and leads to bogus queue positions, since copy maps for all holds are included in the queue position calculation.
Note this does not affect hold capture.
I propose a --retarget-frozen option for the hold targeter so these holds may be forcibly retargeted to refresh their hold copy maps at the users's discretion.
Changed in evergreen: | |
milestone: | 3.1-beta → 3.1-rc |
Changed in evergreen: | |
milestone: | 3.1-rc → 3.next |
Changed in evergreen: | |
milestone: | 3.next → 3.3-beta1 |
Changed in evergreen: | |
milestone: | 3.3-beta1 → 3.3-rc |
Changed in evergreen: | |
milestone: | 3.3-rc → 3.3.1 |
Changed in evergreen: | |
milestone: | 3.3.1 → 3.3.2 |
Changed in evergreen: | |
milestone: | 3.3.2 → 3.3.3 |
Changed in evergreen: | |
milestone: | 3.3.3 → 3.3.4 |
Changed in evergreen: | |
milestone: | 3.3.4 → 3.3.5 |
Changed in evergreen: | |
milestone: | 3.3.5 → 3.4.2 |
Changed in evergreen: | |
milestone: | 3.4.2 → 3.4.3 |
Changed in evergreen: | |
milestone: | 3.4.3 → 3.4.4 |
Changed in evergreen: | |
milestone: | 3.4.4 → 3.5.1 |
Changed in evergreen: | |
milestone: | 3.5.1 → 3.5.2 |
Changed in evergreen: | |
milestone: | 3.5.2 → 3.6.1 |
Changed in evergreen: | |
milestone: | 3.6.1 → 3.6.2 |
Changed in evergreen: | |
milestone: | 3.6.2 → 3.6.3 |
Changed in evergreen: | |
milestone: | 3.6.3 → 3.6.4 |
Changed in evergreen: | |
milestone: | 3.6.4 → 3.7.2 |
tags: |
added: circ-holds removed: holds |
no longer affects: | evergreen/3.3 |
no longer affects: | evergreen/3.4 |
no longer affects: | evergreen/3.5 |
Changed in evergreen: | |
milestone: | 3.7.2 → 3.7.3 |
Changed in evergreen: | |
milestone: | 3.7.3 → none |
no longer affects: | evergreen/3.6 |
Changed in evergreen: | |
assignee: | nobody → Josh Stompro (u-launchpad-stompro-org) |
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
Changed in evergreen: | |
assignee: | nobody → Josh Stompro (u-launchpad-stompro-org) |
Changed in evergreen: | |
milestone: | 3.11-beta → 3.11.0 |
Changed in evergreen: | |
milestone: | 3.11.0 → 3.11.1 |
Changed in evergreen: | |
milestone: | 3.11.1 → 3.12-beta |
Changed in evergreen: | |
milestone: | 3.12-beta → 3.12-rc |
Changed in evergreen: | |
milestone: | 3.12-rc → 3.next |
Changed in evergreen: | |
milestone: | 3.next → 3.12.0 |
Changed in evergreen: | |
milestone: | 3.12.0 → 3.12.1 |
Changed in evergreen: | |
milestone: | 3.12.1 → 3.12.2 |
Changed in evergreen: | |
milestone: | 3.12.2 → 3.12.3 |
Changed in evergreen: | |
milestone: | 3.13-beta → 3.13-rc |
Changed in evergreen: | |
milestone: | 3.13-rc → 3.13.1 |
Changed in evergreen: | |
milestone: | 3.13.1 → 3.13.2 |
Changed in evergreen: | |
milestone: | 3.13.2 → 3.13.3 |
Changed in evergreen: | |
milestone: | 3.13.3 → 3.13.4 |
Changed in evergreen: | |
milestone: | 3.13.4 → 3.13.5 |
To post a comment you must log in.
Bill, I like the idea, but I have a question:
Is there any reason to automatically retarget frozen holds? That is, are you concerned about performance or have other reasons for adding an option to retarget frozen holds and not just do it as part of the ordinary retargeting process?