In an RPC (Remote Procedure Call) design, an interaction across the network is hidden behind a synchronous API that makes the network interaction look (to the rest of the local program) like "just another local function call". The function-call sends its arguments (in some form) to the remote machine, waits for the corresponding reply to come back, and then parses that reply-data to compute a value to return.
That's convenient for programmers who are used to making synchronous/local function calls, as it functions logically the way they are used to, but it seems like there is one big potential fly in the ointment: unlike most local function calls, it's difficult to make any predictions about how quickly an RPC function call will return. That is, even the most trivial "O(1)" RPC-call might get stalled by a temporary network outage, such that the reply-message from the remote machine doesn't come back for several seconds (or even minutes), leaving the local RPC-calling thread "hung" for an unpredictable amount of time.
Once way to ameliorate the problem would be to specify a timeout (e.g. "if the server doesn't reply within 10 seconds, the RPC call should return with an error), but that's not entirely satisfactory either, since if you set the timeout-threshold too high, you still have unacceptably long "hangs", and if you set it too low, you start getting false-positive errors (i.e. where the server did respond, but not quite fast enough to satisfy the specified timeout; and now you'll have to repeat the entire process again unnecessarily, adding yet more load to the server).
Is there some other approach that RPC-based designs use to address this problem, or is it the case that RPC is only appropriate in situations where function-call durations are relatively unimportant, or the network is guaranteed to be "robust enough that this problem won't happen"?