Bug #16448
art should throw if Assns<A,B> is declared but Assns<B,A> is put
Description
An issue recently arose in MicroBooNE where the following was declared in the producer's c'tor:
produces<Assns<recob::Track,recob::Vertex>>();
but an Assns<recob::Vertex,recob::Track>
product was placed onto the event. This can cause problems for looking up the Assns
product later in the same job.
Resolving this issue is not trivial--it requires understanding how the friendlyClassName
of an Assns
product is created and, consequently, how that should affect the product-checking done during the Event::commit
stage.
History
#1 Updated by Kyle Knoepfel over 3 years ago
- Status changed from New to Accepted
After discussion, there may be some inconsistencies with how the friendly class names are formed. Even if those inconsistencies are resolved, significant backwards compatibility issues arise. We will, therefore, discuss this at a later time.
#2 Updated by Kyle Knoepfel over 3 years ago
Inconsistencies in creating the friendly class name have been resolved with commit canvas:22a96e7. The issue was that for testing, the classes A
and B
were defined in an anonymous namespace. The friendly name of each class is therefore (anonymous namespace)::A
. When that pattern is presented to the regex parser, the open parenthesis indicates the beginning of a group. The solution is to escape all parentheses.
In practice, this is unlikely to have been a problem because the context in which friendlyClassName()
is called does not involve classes defined in an anonymous namespace. However, this inconsistency has at least been resolved. If this ever becomes necessary, the (e.g.) (anonymous namespace)::
prefix will need to be replaced with something suitable for a ROOT file branch name.
The problem of detecting when an Assns<B,A>
is placed onto the event instead of an Assns<A,B>
has yet to be solved.
#3 Updated by Kyle Knoepfel over 3 years ago
- Category set to Infrastructure
- Status changed from Accepted to Resolved
- Assignee set to Kyle Knoepfel
- Target version set to 1209
- % Done changed from 0 to 100
- SSI Package art added
The solution was to replace BranchID
-based product checking with TypeLabel
-based checking. Unfortunately, a TypeLabel
is larger in size than a BranchID
, but it was partially mitigated by removing the BranchType
member from the TypeLabel
. It is now an error for an Assns
product with reversed template parameters (with respect to the produces<> call) to be placed onto an event.
With this commit, the following error is also detected:
MyProducer::MyProducer(Parameters const&)
{
produces<A,B>()
produces<B,A>()
}
In this circumstance, an exception will be thrown that looks like:
cet::exception caught in art ---- LogicError BEGIN check_for_duplicate_Assns: An attempt has been made to call the equivalent of produces<art::Assns<B,A,void>>("") which results in a prepared ("friendly") name of: ABvoidart::Assns That friendly name has already been registered for this module. Please check to make sure that produces<> has not already been called for an Assns<> with reversed template arguments. Such behavior is not supported. Contact artists@fnal.gov for guidance. ---- LogicError END
Implemented with commit art:801c3bc9.
#4 Updated by Kyle Knoepfel over 3 years ago
- Target version changed from 1209 to 2.07.01
#5 Updated by Kyle Knoepfel over 3 years ago
- Status changed from Resolved to Closed