Hi JitteryCoyote63 ,
This is behavior is actually a result of a cleanup service running inside the Trains Server, called the non-responsive tasks watchdog . This service is meant to clean up any dangling tasks/experiments that were forgotten in an invalid or running state and did not report for a long time (for example, when you run a development code and simply abort it in your debugger).
The non-responsive timeout (after which such experiments are deemed non-responsive) is currently set to 2 hours, and can be easily changed in the server's configuration (setting is under services.tasks.non_responsive_tasks_watchdog.threshold_sec
, so you can add a services.conf
configuration file and set the non_responsive_tasks_watchdog.threshold_sec
value to any number you wish)
very cool, good to know, thanks SuccessfulKoala55 🙂