You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Retry proposals without CheckpointAck bundles a validator cannot hold
When a validator rejects a proposal with MissingCrossChainUpdate, the updater
first tries to heal it by pushing the sender chain. That cannot work for a
CheckpointAck bundle on a validator that bootstrapped the sender chain from a
checkpoint later than the ack-sending block: the block sits below its tip, is
vouched for by nothing, and is never resent. With enough such validators (plus
ordinary unavailability), a proposal consuming the ack can never be certified,
and the client would keep re-proposing it forever.
The client now settles exactly the acknowledgement bundles named by such
rejections in its local inbox - removing them from the pending bundles and
advancing the lane's sender_pruned_cursor past them, the state a node that
never received them is in - and retries the proposal without them. Skipping
them is always legal: they are Simple, zero-grant bundles, and validators
that do hold one discard it when the lane's next bundle is consumed; if
another owner's quorum does consume it, the certified block reconciles as a
settled no-op. The settlement is part of the chain state, so it survives
client restarts and one-shot CLI commands instead of costing a failed
proposal round-trip each time. A leftover pending proposal from an
interrupted call gets the same treatment rather than wedging every future
proposal. If nothing else is pending, no block is proposed at all.
0 commit comments