-
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
Throw GetByLabelWithoutRegistration exception also when no module in a job registered consumption of a given branch #38875
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38875/31299
|
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages:
@cmsbuild, @smuzaffar, @Dr15Jones, @makortel can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
I don't think this is the proper solution. It seems to miss the case where
This would cause a race condition as to whether A gets the data if A does not also happen to always be scheduled to run after B. |
My point being that |
If B cmssw/FWCore/Framework/src/Principal.cc Lines 805 to 806 in db4ff9a
should return a valid index. In that case the code I added in this PR will not get run, and the existing check cmssw/FWCore/Framework/src/Principal.cc Lines 814 to 816 in db4ff9a
should check if this module declared the consumption of the data product, and throw the GetByLabelWithoutRegistration exception if consumes() was not called.
I think this case was already covered, and I don't see how changes in this PR would impact that. |
What made it not possible to re-use the logic on line 814? |
How about adding a unit test option for this case? |
The cmssw/FWCore/Framework/src/EDConsumerBase.cc Lines 348 to 358 in db4ff9a
would then return false always.
|
I was hoping to get away by |
…nsumes() is not called
…a job registered consumption of a given branch
a8fad0e
to
7b2d9a7
Compare
I added a test that (in the first commit) demonstrates what happens when a data product is obtained via
The changes in the test in the second commit demonstrate the effect of the changes. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38875/31317
|
Pull request #38875 was updated. @cmsbuild, @smuzaffar, @Dr15Jones, @makortel can you please check and sign again. |
@cmsbuild, please test |
-1 Failed Tests: RelVals-INPUT RelVals-INPUTThe relvals timed out after 4 hours. Comparison SummarySummary:
|
@Dr15Jones Does the added test address your concern? |
I'm good with the change once the build system decides to finish its tests :). |
@cmsbuild, please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8f9c39/26569/summary.html Comparison SummarySummary:
|
+1 |
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:
#38864 reported a case where an EDAnalyzer using
Event::getByLabel()
without declaring the consumed data products got aProductNotFound
exception instead of more explanatoryGetByLabelWithoutRegistration
exception. I traced this down toProductResolverIndexHelper
not being populated (fromProductRegistry
withnon-consumed branchesbranches that have product type that is not consumed in the job (either via the same or different branch)cmssw/DataFormats/Provenance/src/ProductRegistry.cc
Lines 419 to 422 in db4ff9a
leading to
ProductResolverIndexHelper::index()
returning aProductResolverIndexInvalid
andPrincipal::findProductByLabel()
returningnullptr
, which is interpreted asProductNotFound
by calling code.This PR proposes to change the
Principal::findProductByLabel()
to check the branch existence directly fromProductRegistry
after gettingProductResolverIndexInvalid
, and throwGetByLabelWithoutRegistration
exception if the branch in question is present. This adds some cost, but only in casegetByLabel()
to get the data, andHandle
validity and is able to ignore the missing productI would expect this case to be rare, and therefore the cost to be acceptable. I also think we should make an effort to address the remaining
getByLabel()
calls in the near-to-medium-future.PR validation:
Checked that the test configuration in #38864 now throws
GetByLabelWithoutRegistration
exception.