JEventProcessorPODIO: treat all unhandled exceptions as fatal

[veprbl]

We are now at a point where quality of the code in factories has been much improved. The exceptions can finally become failures to ensure that we catch the regressions early.

Resolves: #1052
Resolves: #625
Closes: #1053

[wdconinc]

Is this something we are closer to being able to merge?

[github-actions]

Capybara summary for PR 1069

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake
• rec_dis_18x275_minQ2=0_craterlake
• rec_dis_18x275_minQ2=1000_craterlake
• rec_dis_5x41_minQ2=0_craterlake
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2024-05-08T03:21-04:00 eed7e6b}}

[wdconinc]

What's holding this up now?

[wdconinc]

@veprbl What's holding up this PR? It's a nice bit of simplification.

[veprbl]

This doesn't work. We need to figure out how to disable factories without relying on exceptions for control flow.

[nathanwbrei]

Looks like the problem is that in the reconstruction step, the EcalBarrelScFiClusters algorithm needs EcalBarrelScFiHits, but they haven't been put in the file in the digitization step.

[nathanwbrei]

I figure we should change CalorimeterClusterRecoCoG so that the mchits input is std::optional. Right now the algorithm expects the collection to exist, and simply be empty.

[veprbl]

Looks like the problem is that in the reconstruction step, the EcalBarrelScFiClusters algorithm needs EcalBarrelScFiHits, but they haven't been put in the file in the digitization step.

I'm confused about how this even works now.

[nathanwbrei]

Have we been validating anywhere that this test produces meaningful output?

[nathanwbrei]

More specifically, what happens downstream of:

    - name: Upload reconstruction output
      uses: actions/upload-artifact@v3
      with:
        name: rec_${{ matrix.particle }}_1GeV_20GeV_${{ matrix.detector_config }}.edm4eic.root
        path: rec_${{ matrix.particle }}_1GeV_20GeV_${{ matrix.detector_config }}.edm4eic.root
        if-no-files-found: error

[wdconinc]

More specifically, what happens downstream of:

The only thing we do in CI is run a diff with the same file in the main branch. We don't validate performance or require certain performance parameters.

[veprbl]

More specifically, what happens downstream of:

    - name: Upload reconstruction output
      uses: actions/upload-artifact@v3
      with:
        name: rec_${{ matrix.particle }}_1GeV_20GeV_${{ matrix.detector_config }}.edm4eic.root
        path: rec_${{ matrix.particle }}_1GeV_20GeV_${{ matrix.detector_config }}.edm4eic.root
        if-no-files-found: error

Interestingly enough, what happens next is this artifact gets overwritten by a result of eicrecon-gun job:

# gets first step
capybara capy rev HEAD~ --artifact-name raw_e_1GeV_20GeV_craterlake.edm4eic.root
# should get the second step
capybara capy rev HEAD~ --artifact-name rec_e_1GeV_20GeV_craterlake.edm4eic.root

[veprbl]

And, yes, @nathanwbrei, you were right, the second step "works" by simply producing empty output collections:

[veprbl]

I also discovered some older discussion in otherwise invalid PR #1071

[nathanwbrei]

@veprbl points out that the current failure is probably the same as #1226