Where does the data go?

George is right — we do need to track how many times the save has failed. Ben, any quick idea?

Ben

Easy — we can encode the count in the state name itself: failed-2nd-attempt, failed-3rd-attempt...

Thanks Ben — it works. But watch the foot-gun: every new fact multiplies the states. Track timeouts. Track auth errors. Each name is now doing two jobs: where the machine is, and what it has to remember.

Ben

Ugh... this is getting out of hand. How do we track data without breeding new states?

What does the machine carry?

We should split the two jobs, Ben. The state says where the machine is. The context is the backpack it carries — holding what it knows. We'll carry the retries count and the error message in here.

Now, when our machine moves, the backpack moves with it.

We save again — and it fails a second time. The machine moves exactly as before — same failed node. The first failure or the fifth: the count travels in the backpack, not in the state.

And when the save finally succeeds, the context resets. Whatever the data does — reset, grow, persist — the graph never changes shape.

So now the state tracks the position, and the context tracks the machine's memory. Both stay small — each with a single responsibility.

Ben

But... hold on. Shouldn't we check that limit somewhere? If retries keeps growing, shouldn't we stop retrying at some point?

status.ts

1 type Status =

2 | 'idle'

3 | 'saving'

4 | 'failed'

5 | 'saved'