Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Added signed GSF track variable collections to the HLT producer: 14_0 #43774
Added signed GSF track variable collections to the HLT producer: 14_0 #43774
Changes from 3 commits
b4433a0
cf64de5
363a747
360b794
c8dfc09
f2d6925
676482b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
voicing here for the record a concern relayed from @missirol:
New trigger proposals might introduce new modules that do not comply with this customisation, and we might miss it (say they 'migrate' their config, and they do not realise that they have to put True for certain modules).
In the "usual" case, the default value from
fillDescription
is the correct one. We do not need the customisation, and people get the right value after they migrate their config (because ConfDB gives them the default value, which in this scenario is the correct one).In "this" case, it looks like the correct value depends on the specific module and the value of its varTag, so I suspect some people might miss this if they migrate their Paths to 14_0_X (the default will be False, and they may not realise that they need to change this).
Bottom line: to ensure an extra line of defense, would it make sense to enforce at the C++ level that for the affected filters, if
varTag
is among the ones in this list theuseAbs
parameter is checked to beTrue
(and we log an error or even throw otherwise) ?