PermitDynamic and reentry

[hooligan495]

A change made in version 5.14 impacted permitDynamic's reentry logic. This was fixed/changed in 5.16 (see issue #565) In reading this change and it's discussion. The XMLDocs aren't clear that PermitDynamic will in fact call OnEntry with multiple activations of the same trigger.
@mclift looks like you made the final decision here. I must admit that this is confusing. The front of the page documentation says states are not reentrant by default. It appears to me (and I just might be flat out wrong) that there is a mixed mode of behavior here. The facts for the 5.16 change read like so:

`

        sm.Configure(State.A)
            .PermitDynamic(Trigger.X, () => State.A)
            .OnEntry(() => onEntryInvoked = true)
            .OnEntryFrom(Trigger.X, () => onEntryFromInvoked = true)
            .OnExit(() => onExitInvoked = true);
        await sm.FireAsync(Trigger.X);

`

I don't read this as re-entrant but more when you read this example and consider the front page documentation.. that both of these would be called just the first time you enter the state.

I recently created a hierarchical state and set of substates and was using permit dynamic to sequence through my substates. In my example I want to NOT have my substates be reentrant, if I am in state A and I get a trigger that says I need to go to state A I would like for OnEntry function(S) to not be called. Is it possible to make this happen through stateless? Otherwise I'm going to have to code my OnEntry function to manage a form of state in the Entry Function.. which just feels odd to me...

I hope I am speaking in a somewhat articulate manner here? If you could give some guidance that'd be great.

[mclift]

Hi @hooligan495.

Re-reading the discussion and commits against #565, I agree that the README could be improved by making it clear that dynamic transitions allow re-entry. I considered adding new overloads to explicitly set whether re-entry is permitted or not, but at the time I felt that the API surface was already quite large and I was uncomfortable with the thought of adding dozens of new method signatures for this purpose.

As an aside, a thought I kept coming back to is that the API needs to evolve toward a design that allows for greater clarity of intent with fewer method overloads. I expect this was the intent of PR #369, which implements a fluent API for Stateless, but has been left unmerged. Perhaps this work could be revisited and introduced in a more phased approach.