- 
                Notifications
    
You must be signed in to change notification settings  - Fork 53
 
Description
Desired feature/enhancement
Improve the flow control of the execution by adding a can_fail property to the BaseHaddockModule
Motivation
@amjjbonvin: Some modules should not kill the workflow execution
There is no singular implementation currently to control which module can and cannot fail. For caprieval this control was a side effect of  rearrange_ss_capri_output, removed in #1088 and for the other analysis modules this is not yet implemented.
Description
Adding this property we can properly control the execution of the workfow directly in the workflow execution logic:
haddock3/src/haddock/libs/libworkflow.py
Lines 159 to 166 in dfad1e7
| try: | |
| self.module.update_params(**self.config) # type: ignore | |
| self.module.save_config(Path(self.working_path, "params.cfg")) # type: ignore | |
| self.module.run() # type: ignore | |
| except KeyboardInterrupt: | |
| log.info("You have halted subprocess execution by hitting Ctrl+c") | |
| log.info("Exiting...") | |
| sys.exit(1) | 
With something like:
try:
    # ....
except KeyboardInterrupt:
    # ...
except Exception as e:
    if self.module.can_fail:
        log.warning("an exception occured while executing <module name> - but the workflow will continue")
        continue
    log.exception(e)
    log.error("an exception occured while executing <module name> - but the workflow will fail")
    sys.exit(1)With this change, we will also have a "catch all" logic for module's exceptions and an easier way to handle error messages to the users