Hold targeter v2 fails to properly group parallel batches

Bug #1679279 reported by Bill Erickson
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

Evergreen 2.12

The new hold targeter attempts to segregate parallel targeting batches by the metarecord ultimately linked to from the hold target. This prevents any 2 processes from targeting holds that share potential copies. The logic that implements this is flawed, though, because it's grouping on the metarecord_source_map.id column instead of the intended metarecord_source_map.metarecord column. As such, the groupings are essentially random.

Patch en route.

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

Fix pushed:


This is not easily tested via a Perl test, but one way to confirm the fix is to check that the SQL for main holds-to-target query (in parallel mode) now shows:

mod("mmrsm".metarecord, x) = y

Instead of:

mod("mmrsm".id, x) = y

Changed in evergreen:
milestone: none → 2.12.1
assignee: Bill Erickson (berick) → nobody
Revision history for this message
Kathy Lussier (klussier) wrote :


Is this bug ready for a pullrequest?


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

Oops, adding pullrequest. Thanks Kathy.

tags: added: pullrequest
Revision history for this message
Kathy Lussier (klussier) wrote :

Thanks Bill! Merged to master and backported to 2.12

Changed in evergreen:
status: New → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
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.