-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow TriggerResultsFilter
to throw for invalid HLTPathStatus
patterns
#39044
allow TriggerResultsFilter
to throw for invalid HLTPathStatus
patterns
#39044
Conversation
for (auto const& p : m_pathStatusTokens) { | ||
auto const& handle = event.getHandle(p.second); | ||
if (handle.isValid()) { | ||
m_pathStatus.push_back(handle->accept()); | ||
triggerNames.push_back(p.first); | ||
} else { | ||
edm::LogError("MissingHLTPathStatus") | ||
<< "invalid handle for requested edm::HLTPathStatus with label \"" << p.first << "\""; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it was good to add here an error message. I don't know if it should even be promoted to an exception.
} | ||
}); | ||
} | ||
} | ||
|
||
void TriggerResultsFilter::beginStream(edm::StreamID) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The check is done in beginStream
, because the lambda passed via callWhenNewProductsRegistered
is executed only after the module is constructed.
Core-sw experts clarified that the callback in callWhenNewProductsRegistered
is applied serially to the different branches, so .matched
was implemented as a simple bool
, without resorting to atomic
types.
# load conditions from the global tag | ||
process.load('Configuration.StandardSequences.FrontierConditions_GlobalTag_cff') | ||
from Configuration.AlCa.GlobalTag import GlobalTag | ||
process.GlobalTag = GlobalTag(process.GlobalTag, 'auto:run2_mc', '') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the unit-tests, the use of the GT is not strictly needed, so I thought it would be better to remove it.
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-39044/31534
|
A new Pull Request was created by @missirol (Marino Missiroli) for master. It involves the following packages:
@cmsbuild, @missirol, @Martin-Grunewald can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
#process.MessageLogger.cerr.INFO = cms.untracked.PSet( | ||
# reportEvery = cms.untracked.int32(1), # every! | ||
# limit = cms.untracked.int32(-1) # no limit! | ||
# ) | ||
#process.MessageLogger.cerr.FwkReport.reportEvery = 100 # only report every 100th event start | ||
#process.MessageLogger.cerr_stats.threshold = 'INFO' # also info in statistics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why these commented-out lines ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In short, convenience. I used L10 to limit printouts while testing, and I thought it might be convenient to leave these lines there similarly to what is in one of the other configs, triggerResultsFilter_by_TriggerResults.py#L13.
I can remove them if you prefer, of course.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite the opposite... if they are useful for testing, you could also uncomment them, since this is a test file.
Would there be any downsides ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, let me have a look and update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use the snippet below in the 3 configs for the unit-tests. What do you think?
With this, the event number is reported only 10 times instead of 1000, warnings/errors and the TrigReport
messages are reported. The commented-out lines enable all info-level outputs for every event, and are left there for debugging.
process.options.wantSummary = True
process.load('FWCore.MessageService.MessageLogger_cfi')
process.MessageLogger.cerr.FwkReport.reportEvery = 100 # only report every 100th event start
process.MessageLogger.cerr.enableStatistics = False # enable "MessageLogger Summary" message
process.MessageLogger.cerr.threshold = 'INFO' # change to 'WARNING' not to show INFO-level messages
## enable reporting of INFO-level messages (default is limit=0, i.e. no messages reported)
#process.MessageLogger.cerr.INFO = cms.untracked.PSet(
# reportEvery = cms.untracked.int32(1), # every event!
# limit = cms.untracked.int32(-1) # no limit!
#)
60ac149
to
e355f21
Compare
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-39044/31745
|
Pull request #39044 was updated. @cmsbuild, @missirol, @Martin-Grunewald can you please check and sign again. |
type bugfix A small fix, but a fix nonetheless. TSG asked to eventually backport this to |
if (m_eventCache.shouldThrow()) { | ||
throw cms::Exception("Configuration") << "Couldn't parse trigger-results expression \"" << expression << "\""; | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a new addition: I would say TriggerResultsFilter
should throw an exception (not just a warning) if throw=True
and the parsing of the expression fails.
please test The last push
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5b5fbc/27036/summary.html Comparison SummarySummary:
|
+hlt
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This PR updates the
TriggerResultsFilter
plugin to spot patterns without any valid matches whenHLTPathStatus
collections are used (i.e. whenusePathStatus=True
).Up to now
throw=True
had no effect ifusePathStatus=True
, even iftriggerConditions
contained patterns with no valid matches amongst the Paths in the job.All
TriggerResultsFilter
instances in the central HLT menus usethrow=True
, and since many useusePathStatus=True
, those could in principle silently returnFalse
due to invalid patterns (in practise, those patterns are often controlled by theConfDB
GUI, so should be correct).After this PR, invalid patterns for
HLTPathStatus
collections will lead to an exception ifthrow=True
.While testing these changes, small updates were applied to the unit-tests for
TriggerResultsFilter
. In particular,TriggerResultsFilter
modules with valid patterns now usethrow=True
, while those with invalid patterns are those withthrow=False
.Edit : in addition, if
throw=True
, the pluginTriggerResultsFilter
will now throw an exception if the parsing of the trigger-results expression fails (query with invalid syntax); up to now, this was leading only to a warning.Thanks to @fwyzard for much help with the implementation; I tag him to review these changes.
PR validation:
Private tests with the relevant unit-tests.
If this PR is a backport, please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
A backport to(see #39044 (comment))12_4_X
is not necessary, but might be useful.CMSSW_12_4_X