Split service Recovering state into RecoveringReachable and RecoveringUnreachable
The following discussion from !1966 (merged) should be addressed:
-
@Diziet started a discussion: (+1 comment) I have two comments about this.
Firstly, "The service may or may not be reachable" means this status cannot be properly handled by a caller that wants to (for example) wait during startup for the service to be readhable. So I think this status ought to be split, or something.
Secondly, the doc comments form part of the public API but all talk about information that is only available inside the crate, and that a caller can't determine. By writing this here, you're inviting the author of calling code to attempt to figure out how to obtain this other information, which they can't.
I think probably the best thing to do for this MR is to make the ifs and buts be
//
comments rather than doc comments, and make a ticket about the first problem.