Skip to content

Conversation

@tmadlener
Copy link
Member

@tmadlener tmadlener commented Dec 22, 2025

The ExampleFailingSingleEvent test case should exit with a non-zero exit code, because there is an exception that is thrown during the event loop. However, since there is only a single event in the input file and we use EvtMax=-1 this is changed into a user requested ScheduleStop and a non-failing exit code.

Moving the scheduling of this stop into the last action that is done in the IOSvc gives precedence to other exit codes that happen earlier in the event loop inside Gaudi. Hence, we now get the expected failure.

BEGINRELEASENOTES

  • Move the scheduling of the stopping of the event loop to later in the loop to give precedence of other failures during the event loop that would otherwise be shadowed.

ENDRELEASENOTES

Fixes #367

ApplicationMgr(
TopAlg=[failing_alg],
ExtSvc=[EventDataSvc()],
EvtMax=-1, # This is the important part here
Copy link
Member Author

@tmadlener tmadlener Dec 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing this to 1 (i.e. the exact number of events in the input file) gives the same behavior.

edit: Actually any positive value will preserve the behavior of not raising the error properly.

@tmadlener tmadlener changed the title [WIP] Add example that should fail but doesn't Move the scheduling of end of the event loop to later in the loop Dec 22, 2025
@tmadlener
Copy link
Member Author

As a side note: The only test that started failing with a first, slightly more naive move of the check, was FunctionalReadNthEvent. I am not sure if I would have expected more failing tests with this change, but it seems a bit suspicious that none of the other tests that read from an input file did not start to fail. Either all of this is very robust against changes like this, or we have some blind corners in our tests.

The ExampleFailingSingleEvent test case should exit with a non-zero exit
code, because there is an exception that is thrown during the event
loop. However, since there is only a single event in the input file and
we use EvtMax=-1 this is changed into a user requested ScheduleStop and
a non-failing exit code.
Rather than doing it early in the event loop we do it at the latest
point, where we still have access to all the necessary information. This
way any exceptions or other failures should ake precedence over the
ScheduleStop.
There is no easy (i.e. with standard CTest features) way to also check
for a corresponding error message to ensure we got the "right" one.
@jmcarcell jmcarcell force-pushed the should-fail-evtmax-all branch from 282bc6a to 19b1889 Compare December 23, 2025 18:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Using EvtMax=-1 can hide failing executions behind a user requested ScheduleStop

1 participant