BUG: MonteCarlo returns normally after KeyboardInterrupt #1151

Activity

1. ting-hong-shieh commented on Aug 14, 2026

   

   ting-hong-shieh

   on Aug 14, 2026

   Author

   More actions

   I reproduced the interrupt behavior while measuring the slow-test coverage at cb6106a717207dd8fc2dfe1446d80ff75022f21b.

   Command:

   $ pytest tests --runslow -m slow --cov=rocketpy --cov-append --cov-report=

   During test_monte_carlo_simulate[True], sending Ctrl-C did not terminate pytest. The Monte Carlo case returned control to the test, was marked as failed, and pytest continued into the next slow case. A second Ctrl-C was handled the same way; I ultimately had to send SIGQUIT to terminate the run.

   This is consistent with both simulation paths catching KeyboardInterrupt and returning normally after cleanup. It also makes an apparently stalled Monte Carlo run difficult to stop from a test runner or terminal.

   Environment:

   • macOS 26.5.2, arm64
   • Python 3.12.6
   • RocketPy 1.13.0
   • NumPy 2.5.2
   • SciPy 1.18.0
   • pytest 9.1.1

   The intended regression test should assert that cleanup and file persistence finish, then that the original KeyboardInterrupt escapes simulate() in both serial and parallel modes. I will keep the implementation behind #1054 so it does not duplicate or conflict with that process-handling work.
2. ting-hong-shieh commented on Aug 16, 2026

   

   ting-hong-shieh

   on Aug 16, 2026

   Author

   More actions

   Correcting the last paragraph of the report. I wrote that implementation should follow #1054 because that pull request changes the same control flow. It does change it, but it does not close this issue, so the two are independent after all.

   What #1054 does with the interrupt

   Both handlers are rewritten, and both record the interrupt instead of propagating it:

   except KeyboardInterrupt:
       self._interrupted = True
       print("Keyboard interrupt received. Files saved.")
       self.__keep_the_inputs_that_did_not_finish(inputs_json)

   except KeyboardInterrupt:
       _bring_the_fleet_down(started_processes, simulation_error_event)
       self._interrupted = True

   The flag is read in one place, __check_each_index_was_recorded_once, where it suppresses the missing-simulations check:

   missing = (
       []
       if self._interrupted
       else sorted(set(range(self.number_of_simulations)) - set(inputs))
   )

   That is deliberate and correct for what #1054 is about: an interrupted run has gaps in its indices and must not be reported as a corrupt one. But simulate() still runs to its end and returns, so the caller still cannot tell a partial run from a complete one. This issue survives #1054.

   Still reproducing on develop

   At 4263fa95d7fe6f63d9593f01e4ff7a088369e195, serial mode, with __run_single_simulation raising KeyboardInterrupt on the third call where Ctrl-C would:

   Starting Monte Carlo analysis
   Iterations completed: 000001 ...
   Iterations completed: 000002 ...
   Keyboard interrupt received. Files saved.
   __terminate_simulation ran
   
   asked for              : 10 simulations
   completed before Ctrl-C: 2 inputs, 2 outputs
   KeyboardInterrupt seen by caller: False
   

   The two completed rows are intact in both files, which is the behavior worth keeping. What is missing is the last step: simulate() returns as though all ten had run.

   What this changes about the fix

   The proposed fix in the report stands, but the ordering note in it does not. Re-raising after cleanup is a few lines in each handler and does not require the parallel-run rewrite, so it can go in before or after #1054 rather than waiting on it. Whichever lands second is a small rebase.

   A second defect in the same handler

   The serial handler writes inputs_json to the error file, but that name is bound inside the loop body. Ctrl-C during the first keep_simulating() call therefore reaches the handler with nothing bound. At the same commit:

   Starting Monte Carlo analysis
   Keyboard interrupt received. Files saved.
   RAISED UnboundLocalError: cannot access local variable 'inputs_json' where it is not associated with a value
   

   So interrupting early does raise, but it raises the wrong exception from inside the cleanup, after printing that the files were saved.

   #1054 already fixes this by binding inputs_json as the first statement in the loop, with a comment naming exactly this case. Whoever picks this issue up should take that ordering along with the re-raise rather than solving it twice.
3. Gui-FernandesBR

   linked a pull request that will close this issueBUG: re-raise KeyboardInterrupt after an interrupted Monte Carlo run #1177on Sep 11, 2026
4. Gui-FernandesBR

   closed this as completedon Sep 12, 2026