A timeout tells the caller it has stopped waiting, but it does not establish what happened on the server. Suppose checkout asks inventory to reserve two units. Inventory commits the reservation, but its response arrives after checkout has stopped waiting. The caller sees a timeout even though inventory holds the stock. Retrying with a new request identifier could create another hold.
Reliable gRPC APIs must separate the caller's waiting limit from the server's business outcome.
This chapter explains how to budget time, propagate cancellation, report useful errors, and recover without assuming that a failed call means no work happened.