Add sanity checks to BuildIndex() in case of multiple events matching the keys

[TomasDado]

Explain what you would like to see improved and how.

Hi,

currently, if there are mutiple events with the same matching criteria for BuildIndex() with e.g. the same eventNumbers and runNumbers, the code wil not produce any error or warning. However, its almost guaranteed that the output of the code will not be what is expected.

Please note, that this is not a hypothetical issues, we have seen this in ATLAS in many cases and although it was related to limitations of the ATLAS pipelines, there should be some safe guards on the ROOT side.

THe suggestion is to simply throw an error or at least print a warning when during the creation of the hash map for the matching of events a duplicate entry is found.

ROOT version

any

Installation method

any

Operating system

any

Additional context

No response

[ferdymercury]

Would this PR help?
#18964

[TomasDado]

Would this PR help? #18964

Indeed, something like this would be super helpful. The question is if the code should actually stop execution in case of the error - this is up to discussion. But I am not sure what the advantage of processing in case of the error would be as the results would not be reliable.

[ferdymercury]

Hmmm no idea / no strong opinion. Maybe someone is using twice the same file in a TChain by mistake, so the result of the analysis will not be totally wrong.

Unrelated comment btw: there are some limitations of the GetEntryWithIndex function if you have values of event above 32-bit ints. #14967

[TomasDado]

Unrelated comment btw: there are some limitations of the GetEntryWithIndex function if you have values of event above 32-bit ints. #14967

This is interesting. I think this is not a problem for ATLAS, I am not sure we have samples with more than 2B events, but its getting uncomfortably close. Something we will need to keep an eye on.