pub fn request_force_override(
journal: &dyn Journal,
flow_id: &FlowId,
) -> Result<()>Expand description
Arm the one-shot KEEL-E033 force override for flow_id (CCR-6): the next
[side_effect_gate] check that would otherwise refuse this flow’s
re-dispatch (its declared side-effect files changed) proceeds instead, and
clears the flag as it does so.
This is the durable primitive behind keel flows force <flow-id> — the
out-of-process, config-free equivalent of keel exec --force (CCR-5
decision 2). Unlike --force (a purely in-memory per-invocation flag),
this persists a marker step so the override survives across processes and
applies even when no process is currently running against the flow. It
writes through the same Journal handle every exec-time read/write
uses — no second in-process SQLite reader (issue #14).
The caller (the keel flows force verb) is responsible for the UX
preconditions: the flow row must already exist (steps.flow_id is a
foreign key into flows, so arming a non-existent flow errors here) and
should be running/failed — the only statuses [side_effect_gate] gates
— for the arming to have any effect.
§Errors
Propagates any Journal::record_step failure (e.g. the flow does not
exist, or the store is unwritable).