Skip to main content

Module landing

Module landing 

Source
Expand description

How a landing is written into the log (D68).

The queue decides what landed and in what order; it does not know what a landing means to whoever is running it. For a forge bridge it means nothing outside the round – upstream is canonical (D21) and the ordering is the queue’s own bookkeeping. For a node it means the branch moved, which is the whole point, and the op that says so has to be one the daemon’s policy will accept.

Hence a seam rather than a hardcoded op, for the same reason crate::speculate::Speculator is one: the two callers disagree about the answer, and the disagreement is not a parameter.

A refusal is a real outcome, not an error path. The unsigned choir_sequencer::SequencerHandle::submit panics when a policy rejects, so a queue that landed by calling it would take the process down the first time it met a daemon that demands signatures. Every implementation here answers with a Result and the queue stops the round on Err, because a landing the log refused means the base the rest of the train was speculating on is not the base the log has.

Structs§

WorkspaceLanding
The in-memory landing: the change’s workspace now holds this state.

Traits§

Landing
How the queue records that a change landed.