pub trait DeliveryIsRepairedOnDemand: DeliveryAndConsumptionAreOrdered { }Expand description
Lemma (Delivery is repaired on demand, not guaranteed by the sender). A validator makes a
bounded effort to deliver a bundle to its own worker for the recipient chain, and no more. What
makes delivery dependable is that a client needing the bundle can always cause it: the recipient
side of MissingDependenciesAreRecoverable is a repair path, not merely a diagnosis.
Proof. Two halves.
The sender’s effort is bounded. Outgoing cross-chain requests are handed to a bounded channel
with try_send, which drops on overflow, and forward_cross_chain_queries abandons a request
once retries >= cross_chain_max_retries. The persistent outbox keeps the entry, and
ChainWorkerState::create_network_actions re-derives all pending requests from it — but every
call site is a request handler for the sending chain, so nothing re-emits while that chain is
idle. Delivery is therefore best effort in the same sense the notification channel is
(NotificationChannelIsLossy), and for the same reason: no retry outlives the process that
scheduled it.
The recipient can force it. A client proposing a block that consumes the bundle is told
MissingCrossChainUpdate by any validator lacking it, and send_block_proposal answers by
sending that validator the sending chain’s certificates, which re-derives the delivery there.
CrossChainMessageDelivery::Blocking lets a client wait for delivery on an ordinary
send_chain_information request rather than guess. Both are per-validator and on demand. ∎
So the guarantee is conditional on someone wanting the message. A recipient that is not
actively proposing gets no assurance its inbox is complete, and two correct validators can differ
on an inbox indefinitely — the sender-side asymmetry that
super::storage::StorageConvergesAtEqualHeights needs quiescence to rule out. Whether an idle
sending chain should retry on its own is
issue #6799.