-
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
Bug fix for setRunNumberForEachLumi #27649
Conversation
The PoolSource configuration option setRunNumberForEachLumi had a bug that would cause an assert failure if there was an output module running (and possibly other problems because the wrong run number was being used at endRun). Probably no one was using this option because no one noticed the failure before and there is nothing in the repository referencing it other than a Framework unit test. I added an output module to the unit test so this failure would be detected in the IB. This bug should not affect anything if that option is not configured. The code fragment with the bug would not be executed.
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-27649/11181
|
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages: IOPool/Input @cmsbuild, @smuzaffar, @Dr15Jones can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+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. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
The PoolSource configuration option setRunNumberForEachLumi had a bug that would cause an assert failure if there was an output module running (and possibly other problems because the wrong run number was being used at endRun). Probably no one was using this option before now because no one noticed the failure before and there is nothing in the repository referencing it other than a Framework unit test.
This bug should not affect anything if that option is not configured. The code fragment with the bug would not be executed.
PR validation:
I added an output module to the unit test so this failure will be detected in the IB if it recurs.