How to model fsm where actions drive state?

[ursusursus]

Hi, my question is not necessarily about this great library, but possibly a nudge in correct design decision

My usecase is audio calls. I am wrapping access to a very stateful api with a fsm. Api calls are asynchronous.

However, whats not so common in examples is that, if I were to input a transition to "makeCall" in state "idle", which is a valid transition, id output effect of onMakeCall, which would now actually call the api's makeCall, which ultimately drives the call state inside of the library api

In theory its all good, but this ping pong of throwing input in, getting effect out, making the actual method call, throwing another input from callback .. for every single action in the api feels weird.

Also, unluckily enough each api calls can synchronously return / throw error.

So basically I need Idle -> makeCall -> MakeCallPending -> api.makeCall, if not success then -> makeCallFailed -> Idle else from callback -> makeCallSucceeded -> Calling

regardless of library, should this be part of public api? Isnt nesting whole thing cleaner?

When state is Idle 
  When action is makeCall
    state = MakeCallPending
    val error = api.makeCall { 
       onCompleted {
          state = Calling
       }
    }
    if (error)
      state = Idle
    }

This would decrease the number of action objects, which are basically internal boilerplate

Thoughts? Thanks a lot in advance