Decide whether a clustered transfer commit can seal its audit

[gaborbernat]

Problem

crates/peryx-ha-distributed/src/authority_transfer.rs:154 is one of the lines LLVM counts as missed under the total that #2162 enforces, and it is one of only two in the crate that no monomorphization of the enclosing function runs. It is undriven, not unreachable, and which of the two it is decides whether the fix is a test or a code change.

let sealed = receipt
    .transfer_audit
    .ok_or_else(|| TransferDriveError::Unsealed(id.clone()))?;

commit_transfer always submits an intent, so the arm cannot fire through the in-process path:

• authority_transfer.rs:132-141 builds ControlCommand::TransferAuthority { intent: Some(TransferIntent { .. }), .. }, with no branch that leaves intent unset.
• ownership.rs:395-415 returns None from seal_transfer_audit for exactly two shapes, a command that is not TransferAuthority (line 402) and a TransferAuthority whose intent is None (line 404). Neither arises from the call above.
• ownership.rs:378-390 puts that sealed audit on the receipt, so a transfer resolved by the ownership state machine always carries one.

The consensus executor is the other half, and it answers differently:

• consensus_runtime.rs:862-871 matches ControlCommand::TransferAuthority { authority, new_home, .. } and forwards OwnershipCommand::RecordTransfer. The .. drops intent.
• That call returns through submit_ownership at consensus_runtime.rs:995-999, which builds its receipt with committed_receipt.
• committed_receipt at consensus_runtime.rs:1094-1108 sets transfer_audit: None unconditionally.

So a commit_transfer driven through the clustered executor reaches line 154 and returns TransferDriveError::Unsealed.

The open question

What is not established here is whether that is the intended outcome. Two readings fit the code and they need different fixes:

1. The clustered path is expected to answer Unsealed, some later pass recovers the audit through recover_transfer_audits, and the line needs a test that drives commit_transfer against the consensus executor and asserts that error.
2. The clustered path is supposed to return the audit its state machine sealed, and the receipt built at consensus_runtime.rs:999 drops it. Then the line is a symptom and the fix is in the receipt, not in a test.

Reading 2 is worth checking first, because seal_transfer_audit would return None at ownership.rs:404 for the forwarded command in any case: RecordTransfer carries no intent to seal, so the audit the caller asked for cannot be built from what the executor forwards.

Required change

Decide between the two readings, then either drive the arm from a test against the consensus executor, or carry the sealed audit back onto the receipt and drive the arm that remains.

Boundary

consensus_runtime.rs:913 is the crate's other line that no monomorphization runs and is tracked separately as #2201. Every other missed line in peryx-ha-distributed is run by a different instantiation of the same function and is not a behaviour gap.

[gaborbernat]

Resolved: the arm is reachable in production, so it stays, and it now has a test. My original trace was incomplete and reached the wrong half of the executor.

commit_transfer passes Some(&id) as the key (authority_transfer.rs:143), so submission takes the keyed path at consensus_runtime.rs:820-856, not the key: None branch I followed when filing this. That path submits OwnershipCommand::AttemptControl, and the ownership state machine resolves it through attempt_control, which calls seal_transfer_audit and returns ControlResolution::Committed(receipt) with the audit attached (ownership.rs:378-390). Line 830 hands that receipt straight back. So the ordinary keyed commit does seal, and the doc comment I doubted was right about that case.

The fallback is where it does not. When the state machine answers ControlResolution::Claimed rather than applying the control (ownership.rs:370-372, reached when apply_control returns None), consensus_runtime.rs:834-853 runs the command through OwnershipGroup::execute. For TransferAuthority that is consensus_runtime.rs:862-871, which drops intent through the .. pattern and forwards OwnershipCommand::RecordTransfer; the receipt comes back from submit_ownership at :1016-1021 via committed_receipt, which sets transfer_audit: None unconditionally (:1094-1108). The settled receipt returned at line 853 is that one.

So a drive really can be handed a committed receipt carrying no audit, and authority_transfer.rs:154 is the answer it owes the caller when that happens. Neither reading in the issue body was right: it is not a dead guard, and it is not a receipt-construction bug on the ordinary path.

The remaining question this leaves is narrower and worth its own look by whoever owns the ownership plane: on the Claimed fallback the audit is never sealed at all, so a transfer that commits through it has no audit for recover_transfer_audits to find. That is a gap in the fallback rather than in the caller, and it is not what this issue asked.

Covered by #2195, which drives the arm and now names the fallback in its test rather than asserting that consensus always seals.