Function set_event 

pub fn set_event<'a, T, E>(key: &'a str, value: &T) -> PendingStep<'a, (), E> 
where
    T: Serialize,
    E: DurableError + 'a,

Publishes a key/value on the current workflow, for anyone to read.

Setting the same key again replaces the value, which is what makes it a progress channel: the starter app publishes the number of completed steps under one key after each step, and a reader polling DBOS::get_event sees the latest.

The write is checkpointed under a step id, so a replay does not publish again — sysdb sees the recorded step and skips, in the same transaction that would have written. The error is the workflow’s channel, like step’s, so ? needs no conversion.

Only from inside a workflow, and not from inside a step. Outside a workflow there is no step sequence to checkpoint against, and unlike a step there is no plain version of a durable write to degrade to; inside a step, allocating an id would shift every later step onto the wrong replay slot.

The step id is taken at the call, not at the first poll — see PendingStep — so a set built beside a get_event and driven with it by tokio::join! takes the same slot on every execution. The value is encoded first, ahead of the id: a payload that cannot be encoded is a call that never happens, and a call that never happens must not move the counter, or a workflow fixed to encode cleanly would replay onto slots one short of the ones it recorded.