-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
[12_4_X] Use "best matching" EDAlias in module dependence checks when placing ConditionalTask modules in Path #39530
Conversation
…ConditionalTask modules in Path If the EDAlias has wildcards for one module, and more specific aliases for another module, we should use the one that has the most constrained match. There is one ambiguous case left, for which an exception is thrown. I hope we won't encounter that situation in practice. The problem was encountered with a SwitchProducer having the EDAlias case, but I think the problem could happen also without SwitchProducer.
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_12_4_X. It involves the following packages:
@cmsbuild, @smuzaffar, @Dr15Jones, @makortel can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
type bug-fix |
backport of #39409 |
@cmsbuild, please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-7e98ac/27830/summary.html Comparison SummarySummary:
|
+1 |
This pull request is fully signed and it will be integrated in one of the next CMSSW_12_4_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_12_6_X is complete. This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
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.
Could you please tell where this difference wrt what merged in master and in 12_5_X comes from?
Moreover, could you explain why is this needed for 12_4_X: will HLT request a new release for the last few weeks of 2022 data taking with this fix?
@@ -143,6 +144,74 @@ namespace edm { | |||
|
|||
return workerManager.getWorker(*modpset, preg, prealloc, processConfiguration, moduleLabel); | |||
} | |||
|
|||
std::optional<std::string> findBestMatchingAlias( | |||
std::multimap<std::string, edm::BranchDescription const*> const& conditionalModuleBranches, |
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.
These two are std::unordered_multimap
in master and 12_5_X
The
I blindly provided a fix for the release where the problem was seen. I leave it to @cms-sw/hlt-l2 to comment if it is really needed in 12_4_X for the remaining 2022 data taking. (and if not, I'm fine with just closing this PR). |
Currently the HLT menu uses your fix of providing the collection labels explicitely, rather than using |
Closing following the discussion in ORP. If need arises nevertheless, I can reopen the PR. |
PR description:
Backport of #39409. From original description
PR validation:
Tests of #39409, also the original development