{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet-state-machine/stateless/issues/253","repository_url":"https://api.github.com/repos/dotnet-state-machine/stateless","labels_url":"https://api.github.com/repos/dotnet-state-machine/stateless/issues/253/labels{/name}","comments_url":"https://api.github.com/repos/dotnet-state-machine/stateless/issues/253/comments","events_url":"https://api.github.com/repos/dotnet-state-machine/stateless/issues/253/events","html_url":"https://github.com/dotnet-state-machine/stateless/issues/253","id":321807919,"number":253,"title":"What's next for Stateless?","user":{"login":"HenningNT","id":13196280,"avatar_url":"https://avatars0.githubusercontent.com/u/13196280?v=4","gravatar_id":"","url":"https://api.github.com/users/HenningNT","html_url":"https://github.com/HenningNT","followers_url":"https://api.github.com/users/HenningNT/followers","following_url":"https://api.github.com/users/HenningNT/following{/other_user}","gists_url":"https://api.github.com/users/HenningNT/gists{/gist_id}","starred_url":"https://api.github.com/users/HenningNT/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/HenningNT/subscriptions","organizations_url":"https://api.github.com/users/HenningNT/orgs","repos_url":"https://api.github.com/users/HenningNT/repos","events_url":"https://api.github.com/users/HenningNT/events{/privacy}","received_events_url":"https://api.github.com/users/HenningNT/received_events","type":"User","site_admin":false},"labels":[{"id":929226595,"url":"https://api.github.com/repos/dotnet-state-machine/stateless/labels/discussion","name":"discussion","color":"f29deb","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-05-10T04:45:02Z","updated_at":"2018-05-10T21:54:11Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I'd like to push out v4.1 as soon as #249 has been resolved, one of the features added are firing modes.\r\n\r\nWhat should be in v4.2?"},"comment":{"url":"https://api.github.com/repos/dotnet-state-machine/stateless/issues/comments/388197852","html_url":"https://github.com/dotnet-state-machine/stateless/issues/253#issuecomment-388197852","issue_url":"https://api.github.com/repos/dotnet-state-machine/stateless/issues/253","id":388197852,"user":{"login":"prlaba","id":38402381,"avatar_url":"https://avatars2.githubusercontent.com/u/38402381?v=4","gravatar_id":"","url":"https://api.github.com/users/prlaba","html_url":"https://github.com/prlaba","followers_url":"https://api.github.com/users/prlaba/followers","following_url":"https://api.github.com/users/prlaba/following{/other_user}","gists_url":"https://api.github.com/users/prlaba/gists{/gist_id}","starred_url":"https://api.github.com/users/prlaba/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/prlaba/subscriptions","organizations_url":"https://api.github.com/users/prlaba/orgs","repos_url":"https://api.github.com/users/prlaba/repos","events_url":"https://api.github.com/users/prlaba/events{/privacy}","received_events_url":"https://api.github.com/users/prlaba/received_events","type":"User","site_admin":false},"created_at":"2018-05-10T21:54:11Z","updated_at":"2018-05-10T21:54:11Z","author_association":"NONE","body":"Thanks.  My no. 1 suggestion is higher priority, although the workaround currently is to simply add an entry method to each superstate that fires an event to transition to the desired initial substate.\r\n\r\nMy no. 2 is a suggestion in the context of testing/debugging a state machine.  In a deeply nested hierarchical state machine, it’s not unusual to have the same event handled differently by various substates.  In validating the state machine structure its often useful to know which state in the hierarchy successfully handled a fired event.\r\n\r\nThis suggestion is really a small piece of a bigger request for Stateless to provide more access to its “inner workings,” but do so out of band from the state machine’s configuration.  One way to do this would be to have Stateless raise .NET events at various points in the state machine's internal operation (firing of an event, exiting a state, entering a state, performing a transition action, failing an event handler’s guard condition, etc.), so that a client, such as a test harness or trace log, could simply add (.NET) event handlers for those events, and use the returned information (in the passed e EventArg object) to validate the state machine’s configuration or display the state machine’s action.\r\n\r\nContinuing the example I gave earlier, suppose state `A` is a substate of state `B` and state `C` is a substate of state `D`.  I could imagine subscribing to .NET events that would allow me to produce a trace log like this:\r\n\r\n```\r\nEvent E fired from state A.\r\nEvent E guard failed in state A.\r\nEvent E handled in state B.\r\nTransitioning to state C.\r\nExiting state A.\r\nExiting state B.\r\nEntering state D.\r\nEntering state C.\r\nTransition to state C complete.\r\nTransition path: A -> B -> D -> C\r\n```\r\n\r\nWhile it’s possible to do most of this by adding trace statements to the event, entry and exit methods of every state in the state machine, and wiring directly into every event firing method, that’s pretty unworkable for all but trivial state machines.\r\n\r\nPerhaps this capability already exists in Stateless and I’m simply not aware of how to tap into it.\r\n\r\nThanks,\r\n\r\nPaul\r\n"}}
{"actor":{"display_login":"prlaba"}}