It would make handling of timeouts much cleaner if FutureTimeoutError had methods like code()
and details()
etc, the same as, say, _InactiveRpcError does.
Is this a design decision? Would the grpc community be open to a pull request that changes the implementation of FutureTimeoutError in this way?
grpc.FutureTimeoutError
is the exception raised when a grpc.Future.result
or grpc.Future.exception
exceeds deadline but haven't got any result. For example, the RPC takes 10 seconds to finish, but we got result(timeout=2)
. Then the grpc.FutureTimeoutError
will be raised to indicate time's up after 2 seconds. And the RPC isn't near finishing at that time, so we can't access code()
and details()
.
This is not a RPC issue on either the client or the server, which means grpc.RpcError
may not be a good fit for grpc.FutureTimeoutError
.