Open plastikfan opened 3 days ago
This problem of saving active state and use of the panic handler when an in-line sync is in play. That is, if a panic occurs during navigation the default panic handler instigate a save of the active state.
But what happens when a parallel sync is in play; ie the client has invoked Run instead of Walk? This will be addressed by another issue but we can speculate what should happen.
Currently the client handler will be invoked but in a separate go routine. That means that the recovery mechanism built into the mediator (running in the main thread) will not be able to rescue the panic. Instead the remote job will have to handle the panic and return an appropriate error. To match the functionality in th einline sync, the worker pool will probably have to review the return error from the job and cancel the work pool.
currently there is no association of ActiveState with the process of launching a save of the currently navigator state. This should probably be done using the navigationStatic and navigationVapour.
It can't be up to traverse to instigate a resume save. The client application should be resposibile for trapping a ctrl-c interrupt then calling a method within traverse to save the current state. The exception to this is if an unhandled panic occurs which the default panic handler can handle implicitly which in turn invokes save.