Snapshot validation reports named errors and non-fatal warnings
Validating a snapshot against a workflow definition answers with codes a caller can act on, and draws a hard line between what invalidates a snapshot and what is merely worth saying.
The rule
- Validating a snapshot against a workflow definition yields a result carrying named codes.
- Errors, each of which makes the result invalid: a version mismatch, raised only when the snapshot's workflow version is non-empty (an empty version skips the check and is not an error); one unknown-node error per snapshot node absent from the definition; and one dependency-not-met error per completed node whose dependency has no recorded state or is neither completed nor skipped.
- Warnings, which never make the result invalid: one per definition node missing from the snapshot, and one per completed injected node that has dependencies.
What it means
Validating a snapshot against a workflow definition treats two kinds of mismatch very differently. A snapshot node the definition no longer knows — the graph changed under a run that is trying to resume into it — is an error: the result is invalid and resuming must not proceed. A definition node the snapshot has simply not reached yet is only a warning: that is the ordinary shape of a mid-run snapshot, and a warning must never flip the result invalid, or every resumable snapshot would be refused.
The version check has an exception worth naming: an empty snapshot version skips the comparison entirely rather than counting as a mismatch. A snapshot built with no known version has nothing to compare, and treating "unknown" as "different" would refuse every such snapshot regardless of the definition it is checked against.
Example
The workflow declares two nodes, node_1 and node_2. Only node_1 has
completed so far.
{"id": "unknown_node"}{"id": "node_2"}{"code": "WARNING_ORPHAN_NODE", "nodeId": "node_2"}The first case invalidates the result; the second is recorded as a warning and the result stays valid.