bug: Events triggered via sml::back::process<TEvent>() are not processed in parent state  #562

Activity

1. rhaschke

   changed the title [-]bug: Events triggered via sml::back:process<TEvent>() are not processed in parent state [/-] [+]bug: Events triggered via `sml::back::process<TEvent>()` are not processed in parent state [/+] on Mar 6, 2023
2. rhaschke

   added a commit that references this issue on Mar 18, 2023

   Add (failing) unit test for boost-ext#562

   ...

   4be9dd6
3. rhaschke commented on Mar 18, 2023

   

   rhaschke

   on Mar 18, 2023

   Last edited by rhaschke

   ContributorAuthor

   More actions

   I analyzed this issue a little bit and found that the event triggered via sml::back::processs is injected into the sub state's process queue instead of using the root state's one:

   back::process	process
   sml/include/boost/sml.hpp Line 1873 in 4be9dd6 return back::process<TEvents...>{sm.process_};	sml/include/boost/sml.hpp Line 2128 in 4be9dd6 aux::get<get_root_sm_t<TSubs>>(subs).process_.push(event);

   A similar issue was resolved in #302 for process, which actually works correctly now.
   I added a (failing) unit test in my fork to illustrate the problem.

   To resolve that issue here in a similar fashion, one would need to access the root sm in get_arg, which is not available yet. However, instead of applying this kind of fix again, I want to fundamentally question the design:
   Why do we need the process_ queue in all sub state machines at all? Doesn't it suffice to have a single one in the root state machine - as we need to process all events from there? All subs could simply have a pointer to that single queue instance, such that we don't need to change API of get_arg.

   For deferred events the story is different I think: they should be kept in state-local queues and be processed as soon as the state is left.
4. J-Meyers

   added 2 commits that reference this issue on May 9, 2023

   Add (failing) unit test for boost-ext#562

   ...

   ae0b517

   Attempt at progress towards boost-ext#562

   df267e0
5. PavelGuzenfeld commented on Oct 13, 2026

   

   PavelGuzenfeld

   on Oct 13, 2026

   Contributor

   More actions

   Fixed by #687, the repro prints the failure as expected on master 4970fef. Can be closed.
6. PavelGuzenfeld commented on Oct 17, 2026

   

   PavelGuzenfeld

   on Oct 17, 2026

   Contributor

   More actions

   @kris-jusiak can you close this? Fixed or answered, see the comment above.
7. kris-jusiak

   closed this as completedon Oct 18, 2026