Bug #23054

getValidHandle fails when products differ only by process name

Added by David Brown about 1 year ago. Updated 9 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spent time:
Occurs In:
SSI Package:


When reading an input file containing a product "myProducer_myProduct" getValidHandle will throw if the path includes an instance of myProducer, even if that module has not been run at the time getValidHandle is called. This is a new problem arising in art3, Rob believes it was triggered by a change in the default rules for handling ambiguous tags compared to art2. There are actually 2 bugs:
- the call to getValidHandle is actually unambiguous as only 1 match to "myProducer_myProduct" exists in the event when called and so it should not throw
- the message on throw "getByLabel: Found zero products matching all criteria" is incorrect and misleading, making it very hard to debug

To reproduce, run the included script 'mu2e -c getValidHandle.fcl'

getValidHandleBug.fcl (6.78 KB) getValidHandleBug.fcl David Brown, 08/04/2019 01:35 PM


#1 Updated by Kyle Knoepfel 12 months ago

  • Assignee set to Kyle Knoepfel
  • Status changed from New to Assigned

We will investigate.

#2 Updated by Kyle Knoepfel 12 months ago

  • Status changed from Assigned to Feedback

Dave, can you tell me which branch/commit I should use in Mu2e Offline to reproduce this error?

#3 Updated by Kyle Knoepfel 12 months ago

  • Status changed from Feedback to Assigned

Nevermind; I was able to reproduce the error by removing all 'input_source' and 'current_process' process names from the FHiCL file.

#4 Updated by Kyle Knoepfel 12 months ago

The problem is understood. We can certainly improve the error message, although what the behavior should be in this circumstance requires some discussion. I will await further comments from Mu2e before committing to a particular plan of action.

#5 Updated by David Brown 12 months ago

Hi Kyle, where would you like to hold the discussion? at a Mu2e computing/software meeting or in an art stakeholders meeting or privately?

#6 Updated by Kyle Knoepfel 12 months ago

  • % Done changed from 0 to 100
  • Status changed from Assigned to Resolved
  • Category set to Infrastructure

Turns out the fix was reasonably straightforward to implement. I will consult with the rest of the SciSoft team to determine a suitable time scale for releasing a new version of art.

Fix implemented with commit art:afb35c3.

#7 Updated by Kyle Knoepfel 9 months ago

  • Target version set to 3.04.00

#8 Updated by Kyle Knoepfel 9 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF