Consolidate "Not Synced" Error Messages

[mDuo13]

Summary

The server has several different types of error messages it may return when you make an API request it cannot serve because it is not fully synced to the network. We should consolidate these into a single error message.

Motivation

There are at least three universal errors that mean basically the same thing: the server isn't connected to the network. These are:

• noNetwork
• noCurrent
• noClosed

On top of that, there's at least one more command-specific error message, lgrIdxsInvalid, which can happen as a result of not being synced. There may be more I don't know about.

The distinctions between these types of errors are not useful for API consumers who just want to know why their request didn't go through. In theory, the differences might have been helpful for debugging, but in practice, the action an API should take after getting basically all of these messages is the same:

• Wait for the server to finish syncing
• If you're the server admin, debug why it's not synced by looking at server_info.

Having different error messages for all these similar cases just makes it harder to look up, harder to recognize a familiar situation, and harder to handle automatically as a client.

Solution

We should consolidate all these error messages into a single message, notSynced or something along those lines. If the server is not synced, or is still in the startup phases (even in stand-alone mode) it returns this error instead of any of the above errors.

Paths Not Taken

I considered maybe there should be a different error, such as notStarted, for when you query a stand-alone-mode server too early in the startup process, but decided it didn't seem like a significant enough case to warrant a different error.

[HowardHinnant]

Do we need to go through a deprecation period where both the old errors and the new error coexist prior to removing the old errors?

[mDuo13]

I think the existing codes are piecemeal and inconsistent enough in this case that it seems unlikely to actually break someone's code, but I could be wrong about that.

To be safe, I think it might be necessary to bump the API version for this change, which would mean the old API version would use the old codes and the new API version would use the new unified error code.