Cryptic Error Messages

[shikokuchuo]

@wlandau I just realised why the mention of 'cryptic error' - it is as the human readable error is not passed on - and printing out the dput() value looks strange.

The print method for 'errorValue' uses nng_error(). Then at least the user will know that a 5 is a timeout for example.

In the next CRAN version, if dispatcher is not alive, the error will become 11 incorrect state (technically, the send is now synchronous and will fail if it doesn't connect within 5s, then when the receive is attempted, it is in an 'incorrect state').

It might be an idea to translate this on the crew side. A timeout error 5 would then truly be something exotic (dispatcher is alive but fails to respond).

[wlandau]

Thanks for looking into this. crew's error handling code for mirai::status() is at https://github.com/wlandau/crew/blob/main/R/utils_mirai.R. In a nutshell, crew prints deparse1(mirai::status()$daemons) in case of an error, then manually checks if the dispatcher is still running. I think this all still holds with the changes you have in mind, but if I am missing something, a PR to update https://github.com/wlandau/crew/blob/main/R/utils_mirai.R would help me understand.

Related: another awesome thing about shikokuchuo/mirai#78 is that crew will have the option to completely avoid mirai::status() (except for controller$client$summary(), which almost no user is going to care about). I am not sure, but that might take care of the source of these errors. On the other hand, if the dispatcher silently hangs, then that could be worse. I wonder if frequently-used crew methods like controller$push() and controller$pop() should periodically check the health of the dispatcher.

[shikokuchuo]

That's really cool I didn't realise it contained all this extra information. I note in #128 we have dispatcher running at pid 881616 with status "disk_sleep". I haven't seen this before, but perhaps is a clue?

I'll put through a PR though to make it better for the 'errorValue' itself.

Re. your comment on dispatcher - I don't think it can ever hang. It can error or get killed. Then we get an error when we try to query it.

[shikokuchuo]

Also if that happens, any existing unresolved mirai will return 'errorValue' 19 connection reset now. This is if dispatcher dies then the situation is irrecoverable and we need to re-launch. We don't even hang waiting for mirai to resolve. This is for the upcoming release.

[shikokuchuo]

This was addressed by PR #130.