Matti Kortelainen

> Could it have been avoided in any way? It might be technically possible to craft an iorule for the new versions of the classes to ignore the corresponding content...

Seems that the problem 1 occurred in Run 3 workflow (input dataset being `/RelValTTbar_14TeV/CMSSW_12_5_0_pre4-PU_124X_mcRun3_2022_realistic_v10-v2/GEN-SIM-DIGI-RAW`)

I tried to reproduce problem 1 by generating the `step_2_cfg.py` as in https://cms-pdmv.cern.ch/relval/api/relvals/get_cmsdriver/CMSSW_12_5_0_pre5__AUTOMATED_fullsim_PU_2022_14TeV_RECOonly-TTbar_14TeV-00002, and instead of the exception message shown in the description I get a segfault ``` #3 0x00007ff533491aeb...

I was able to reproduce the exception with `del process.hltExoticaValidator`. I also started to wonder one aspects in this workflow. The problematic data product is being read by a (HLT)...

My attempts for an iorule workaround didn't succeed, and after consulting @Dr15Jones that would really be against what we try to achieve with iorules. The framework works hard to ensure...

The `redefinition of 'TrackingRecHit2DHeterogeneous'` error comes from `edmCheckClassVersion` (I'd guess from ROOT underneath). @smuzaffar Would you have any idea what could be going wrong there? On the other hand, scram(?)...

assign reconstruction

FYI @cms-sw/egamma-pog-l2 @cms-sw/muon-pog-l2 @cms-sw/tracking-pog-l2

@cmsbuild, please test

hold This is more for 13_0_X.