I spent some time working on the design to solve this:
One thing I did not see initially
‘Press F5’ means a new bot operation session is started. This, in turn, means that the ‘internal problem’ of the script is visible in the end session log. If the continuation happened in the same session, the ‘internal problem’ of the script would be less visible.
Further context informing the design
Since ‘press F5’ also means that state in script variables is lost, a problem leading to a new start can be actually expensive, since a script might perform some setup activities before value-adding in-game activities are performed.
Because of these costs, it is desirable to have a user interface which supports finding the relevant information in the large amount of data recorded with bot operation.
Candidates for Solutions
The reported problems in scripts which lead to such sporadic failures usually result from using the C# programming language to code the overall bot logic. As the many error reports on the forum show, the runtime exceptions of C# and .NET are an example of how such problems can easily be introduced in script code without even noticing.
So far, the best approach to fix these issues seems to be using a language which is actually suitable for programming bots, offering fewer ways to introduce subtle bugs. For example, it would not contain problematic constructs such as runtime exceptions.
As there are already successful implementations of such languages, necessary tools like compilers, interpreters, static code analysis, libraries could be adapted and reused here, similar to how the C# compiler is integrated with Sanderling. I expect to spend some coffee and time on efforts to make this happen.
On a parallel track, the ‘auto F5’ can be added as a band-aid quick fix to the existing Sanderling app. This functionality could be supported with a command-line argument, analogous to the existing ones.