PartitionedRouter
The Partitioned router: a command runs on the owner of its log partition, whose state cache is warm and who appends without contention.
A command of a context this node has no lease group for in groups (keyed by context) runs locally.
A command for a partition this node holds and accepts runs here, counted for the partition's hand-off.
Otherwise it is forwarded over channel to PartitionOwnership.forwardTarget by its deadline, ClusterOptions.forwardTimeout from then, capped by the command's own wait deadline. The timeout is the request's: the channel connects to the peer first, within the wait's deadline, so the first forward to a peer that started a moment ago does not spend its second opening a connection. The forward then reserves one of the peer's streams, waiting its turn while they are all taken, until its deadline, and is sent once it has one.
A forward the owner surely did not receive degrades to running locally, without retrying it: no known owner, the peer's ClusterOptions.maxInFlightPerPeer reached, the peer unreachable or not connected by the wait's deadline (ClusterChannelException.unsent), or a refusal before the forward's deadline (Refusal.NOT_OWNER, Refusal.EXPIRED, or a type the peer does not know): the peer did not run it.
Past its deadline a forward runs nowhere: one not sent by then (no stream to the peer was free, or its wait ran out before it could be sent), or refused after it, is withdrawn (ResultCodes.WAIT_TIMEOUT) once its wait has run out, as a command still queued in its lane at its wait's deadline is, and answered busy (ResultCodes.BUSY) while it has not, as a full lane is. Either way it was not executed, so it is not reported unknown; and running it here instead, under the load that kept it from the owner, would put a second writer beside the owner.
A forward that was sent waits for the reply until its deadline and the channel's ClusterChannel.answerGrace after it: the owner answers a command it withdraws at its wait's deadline just after that deadline, and that answer (ResultCodes.WAIT_TIMEOUT, not executed) is the outcome. One that got no reply by then, or failed after it was sent, does not degrade (revising): the owner may be deciding it still, and deciding it here too would run a decide that does I/O twice. Its outcome is ResultCodes.UNKNOWN; a retry with the same request id is answered from the owner's commit, if any. So route answers a forward at most the grace after its deadline; a waited command's wait still ends at its own deadline.
A failed forward also refreshes the routes. Degrading is safe without fencing: the kernel deduplicates by request id, and version-unique keys turn concurrent writers into conflicts that are decided again.
A command runs under ExecutionLease.HELD when this node holds its partition, else under ExecutionLease.NOT_HELD: only the owner's kernel caches the states it loads and lets a decide that does I/O skip the request-id lookup.