fix: clear the transition when the context is canceled

[dunv]

Fixes #115.

transitionFunc returns early when ctx.Err() != nil, but only the completed path below it clears f.transition:

transitionFunc := func(ctx context.Context, async bool) func() {
    return func() {
        if ctx.Err() != nil {
            if e.Err == nil {
                e.Err = ctx.Err()
            }
            return                     // f.transition left set
        }

        f.stateMu.Lock()
        f.current = dst
        f.transition = nil             // only cleared here
        f.stateMu.Unlock()
        ...

Since f.transition is published before the context is ever checked, a canceled context leaves the FSM in transition — and permanently, because there is no way back:

• every later Event returns InTransitionError,
• Can() returns false (ok && (f.transition == nil)),
• and Transition() cannot help either: it re-runs this same closure, which captured the same dead context and takes the same early return.

Only constructing a new FSM recovers.

Why it looks intermittent

Whether a canceled context bricks the FSM depends on which state is being left, which is not something a caller would think to check:

• a state whose leave callback cancels is spared — leaveStateCallbacks returning CanceledError does clear the flag;
• a state with no callbacks is not.

So the same cancellation is harmless in one state and terminal in another.

The fix

Clear f.transition on the canceled path, taking the same stateMu lock the completed path takes. e.Err is left untouched, so Event still returns the context error to the caller exactly as before — this only stops the FSM being unusable afterwards.

Test

TestCanceledContextDoesNotLeaveTheFSMInTransition — an FSM with no callbacks, one event with an already-canceled context, then a second event with a live one. Before the fix it fails with:

expected the FSM to still accept events, got event run inappropriate because
previous transition did not complete

After it passes, and the full suite passes under -race.

Where this came from

A cart-fleet sync service, one FSM per sync rule, with the context being the gRPC stream. A stream dying while an event was in flight left that rule's handler refusing every transition until it was rebuilt, so it silently stopped syncing and queued everything it received instead. It showed up on 34 devices in three days, and was hard to see because the resulting error is indistinguishable from ordinary "wrong state for this event" noise unless you look at the wrapped cause.

[maxekman]

Thanks for the fix, will check it out.

[coveralls]

coverage: 92.936% (+0.05%) from 92.889% — dunv:fix/clear-transition-on-canceled-context into looplab:main