DPL: attempt at adding the run number to timers and enumerations#14135
DPL: attempt at adding the run number to timers and enumerations#14135ktf merged 1 commit intoAliceO2Group:devfrom
Conversation
|
REQUEST FOR PRODUCTION RELEASES: This will add The following labels are available |
|
Error while checking build/O2/fullCI_slc9 for fcdd7f3 at 2025-04-02 13:43: Full log here. |
We use it only with data inputs. It should be safe to change it with regards to QC. Unless it can break the latest possible timeframe computations? |
|
In principle timers are already skipped for that... |
|
Should we perhaps reserve special runnumbers we put in there, instead or initializing to 0 in case of failure? Then we would at least know why we get invalid run numbers. |
|
yes, I was thinking about it however I wanted to minimise changes to the current behaviour. |
| try { | ||
| dh.runNumber = atoi(services.get<DataTakingContext>().runNumber.c_str()); | ||
| } catch (...) { | ||
| dh.runNumber = 0; |
There was a problem hiding this comment.
| dh.runNumber = 0; | |
| dh.runNumber = -1; |
@davidrohr something like this?
There was a problem hiding this comment.
Probably I would rather reserve a range of ~100 invalid positive numbers with meaning, like we have a range for unanchored MC. You can discuss the range with @ehellbar and RC.
Then, the invalid runNumber check would also need to check for that range. And if we get an error with a number from that range, it is clear how it happened.
|
Error while checking build/O2/fullCI_slc9 for 3f8e858 at 2025-04-02 19:32: Full log here. |
No description provided.