Class WorkflowCheckpoint

Namespace

Millrace.Storage

Assembly

Millrace.dll

A workflow instance update carried inside a JobTransition, so the checkpoint commits in the same transaction as the activity job's own transition.

public sealed record WorkflowCheckpoint : IEquatable<WorkflowCheckpoint>

Inheritance

object

WorkflowCheckpoint

Implements

IEquatable<WorkflowCheckpoint>

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

Why this exists. §6.2 makes the activity the unit of at-least-once execution and the checkpoint the unit of exactly-once progress. Two separate calls cannot deliver that, in either order: checkpoint-then-transition lets a crash re-run an activity from a cursor that already moved past it, and transition-then-checkpoint lets a crash strand the instance forever with no failure recorded. The coupling has to be expressible in one atom, which is what this is.

It is the direct analogue of Enqueue: the engine computes a command and the provider applies it all-or-nothing, so no engine logic — cursor arithmetic, merge policy, graph traversal — moves into a provider (§4 P2).

Conflict signalling. A stale ExpectedRevision throws MillraceConcurrencyException rather than returning false, because the caller must react: reload the instance and retry the merge. A fence rejection still returns false, because there the loser simply drops. Keeping those two outcomes distinguishable is why the checkpoint does not reuse the boolean.

Properties

ExpectedRevision

The revision the engine read. The update applies only if the stored revision still matches.

Instance

The instance as it should be stored. The provider writes it with Revision = ExpectedRevision + 1, exactly as UpdateInstanceAsync does.