The previous implementation ended up causing more issues and overall introduced several other bugs.
The main culprit was found when testing a call scenario where the participant had a role of guest. Under these circumstances, a child participanat token cannot perform any actions on the parent participant (even though they're effectively the same), resulting in most calls either failing with proper HTTP response or in some cases emitting 200 without modifying state.
This PR flips things a bit and make all calls via child participant with an appropriate token, but uses parent participant to identify self in the roster. This is necessary since child participant does not participate in populating the roster, only their parent does.
To simplify things a bit we switched from lazily creating instances of ParticipantStep to pre-allocating them on participant_create event with a small indirection in the presence of parent participant.
The previous implementation ended up causing more issues and overall introduced several other bugs.
The main culprit was found when testing a call scenario where the participant had a role of
guest. Under these circumstances, a child participanat token cannot perform any actions on the parent participant (even though they're effectively the same), resulting in most calls either failing with proper HTTP response or in some cases emitting 200 without modifying state.This PR flips things a bit and make all calls via child participant with an appropriate token, but uses parent participant to identify self in the roster. This is necessary since child participant does not participate in populating the roster, only their parent does.
To simplify things a bit we switched from lazily creating instances of
ParticipantStepto pre-allocating them onparticipant_createevent with a small indirection in the presence of parent participant.