Module 06 Activity

Scenario

The workflow needs to survive a restart, and that changes what every node has to be correct about.

What you build

A checkpointed graph with a deliberate state schema, verified to resume from a fresh process without repeating side effects.

Steps

1. Add a checkpointer and choose thread ids that mean something in your domain - an order id, a ticket id, not a uuid.
2. Sort every state field with the two questions from Unit 01: can it be serialised, and would resuming be wrong without it. Remove what fails both.
3. Measure your state size on a realistic input, then multiply by your step count and expected runs. Report the projected storage.
4. Verify a side-effecting node does not repeat on resume - and verify it from a genuinely separate process, not a second call in the same script.
5. Use get_state_history to find a bug you plant deliberately in a middle node, without adding any print statements.

Evidence to hand in

• The state schema with the keep/drop decision and reason per field.
• The projected storage figure with its arithmetic.
• Evidence that a resume from a fresh process did not repeat the effect.
• The history output showing where your planted bug first appears.

Review checklist

• No secrets and nothing unserialisable are in the checkpoint.
• Document contents are stored as ids unless a reason is given.
• The storage projection multiplies by both steps and runs.
• The resume test uses a separate process.
• The planted bug was found from the history, not from print statements.

Mark complete