Skip to main content

dispatch

Function dispatch 

Source
fn dispatch(
    actions: &[SessionPixAction],
    closed: bool,
    action_tx: &MAsyncTx<Array<SessionPixAction>>,
    gate: &Arc<ServiceGate>,
) -> bool
Expand description

Apply gate control, forward actions, then report whether the worker should keep running.

The four places that produce actions — the two deadline paths in worker_loop and the two command arms in process_cmd — all had the same four-way branch spelled out: send, check whether the supervisor closed, poison, return. Fail-close is the property that matters most here and it was stated four times, so a correction to it had to be made four times.

Poisons the gate on every terminal path, so no caller has to remember to. closed is passed rather than read from the supervisor because the callers hold it by different borrows.

Terminality is derived from the actions as well as from closed, because the two do not always agree: several handlers return Close without setting the supervisor’s flag — both InvalidTransition paths in on_ssa_request_sent, CounterRegression and the share-order verdict in on_recovery_progress, and on_unverifiable_shares. Two of those are the anti-abuse verdicts. Reading only the flag would send the close, return true, and leave the gate open for as long as it takes the action driver to poison it on receipt — which is a real but bounded window, not a correct one. Close is also the one action the driver never reports back, so action_result’s own close path cannot cover for it.