Looking at the callback orderings, it seems that transition callbacks are pretty inconsistent with event callbacks.

Event goes: before -> guards -> success -> after -> after_all_events

But Transition goes: guards -> after_all_transitions -> after -> success

It's seems logical that an after_all should come after after, and it seems potentially dangerous that after and after_all are both called before success meaning if, say, there's a temporary network issue and the db write fails, it could still trigger the after callbacks (which might write to an external service or something, leading to an inconsistent state).

Is it at all feasible to re-order transition callbacks to be consistent with how they're defined for event (i.e. success -> after -> after_all) ?

My immediate issue is that I need to insert some logic after a transition, but before my after_all_transitions method. A less comprehensive but backwards compatible solution would be just to add an after_guards transition callback or something like that, which gets called right before after_all_transitions