Where does the limit live?

You're asking the right questions, Ben. Any idea where that limit check could live?

Ben

Well... we could put an if inside the retry handler? But I'm not sure — every bit of logic we hide in handlers gets harder to track...

You're right to hesitate — but let's build it anyway, and see it fail. We wrap the retry in an if, move and bump the counter inside, and otherwise... silently do nothing.

After three failures, RETRY fires again. The check fails, so nothing happens. The machine stays in failed — and nothing on the map explains why. The reason is hiding in the handler.

What if the rule lived on the door?

So think deeper, Ben. If the map should explain it — where does the rule have to live?

Ben

Hmm... on the machine itself? Like... putting the condition on the arrow, right next to the transition it controls?

Exactly — great thinking, Ben. This is a guard — a door with its rule printed on it. We take the RETRY transition, name its target, and print the rule right on it. The event knocks; the guard decides.

One retry so far. The event knocks — the guard says true. The door opens. We move to saving.

Now three retries. Same event, same knock. What does the guard say?

false — and the door stays shut. We stay in failed, but not silently: the rule is printed right on the door.

Congratulations Ben! Now every condition that controls a transition lives on the machine — visible, named, testable.

George

Congratulating yourselves again, gentlemen? Your tidy little machine is naive — it never actually does anything. What really saves, when you move from idle to saving?

handler.ts

1 function handleRetry() {

2 }

context · retries: 1