Subtrees sometimes stop after first behavior in sequence

I’m seeing some baffling behavior since going to SDK 1.2. In two cases where I have a Subtree calling another Subtree, I have occurrences of the second Subtree “succeeding” after it executes the first behavior in its sequence, skipping over the remainder of the Subtree.

For one of these Subtrees, this happens every time. For another, it happens every other time. Very strange.

I don’t get any errors in the developer console. When I throw in log messages to trace where I am, execution just seems to skip after that first Subtree behavior to the next expected behavior past the Subtree call.

From sample code I can see how to collect and report status for a Behavior when created with jibo.bt.create, but I can’t find an equivalent method when the Behavior is called from a Subtree behavior, so I can’t tell if the Subtree is dying on an error that doesn’t get displayed in the console.

When I skip the Subtree call, placing the code from the Subtree directly in the calling behavior, the issue clears up.

Here’s my current version info:

SDK: 1.2.7
jibo module: 2.0.3
behaviorify module: 1.0.0

For reference, the failing code is at https://github.com/chrooke/jibo-knock-knock/tree/master, and the version that works with the subtrees replaced with the sequences is at https://github.com/chrooke/jibo-knock-knock/tree/flatten-some-subtrees

The specific subtrees that show the issue are HearAJoke.bt called from KnockKnock.bt (this is the one that cuts short every time after the first time through), and the ‘Sorry’ call to attitudes/react.bt found in HearAJoke.bt. This is the one that skips every other time.

1 Like

Hi Chris!

I think I see what is going on!

If I am understanding your question, you are seeing behaviors like HearAJoke.bt only get through the first part of its first sequence on the second time that sub-tree is executed.

The reason for this is that the rest of the sub-tree starts with a Sequence*(WhileCondition) that has an init decorator argument that has the following code in it:

() => {
//  console.log(' main loop');
  notepad.MainBreak=false;
}

If notepad.MainBreak doesn’t get initialized in this way the rest of the sub-tree will not execute.

The reason this is happening is due to the nature of while loops like this.

When you loop a sequence using a WhileCondition any initialization you do via decorator arguments only initializes the first time that sequence runs that behavior/decorator argument. Any subsequent times that sub-tree executes the initialization will not occur again.

I hope that is helpful!

Thanks for looking at it John.

If the initialization never occurs again, would that mean the next time I leave and re-enter the subtree I should expect it to have it’s old value? That’s not what I see. I see it appear as undefined every time I re-enter the subtree.

I move all the initialization of the while decorators out of the decorators, but I still see the behavior. Actually I misspoke above, twice. The effect does happen every other time in both instances, and it’s not a skip to the end, it’s a pause and continue, like the TellOneJoke subtree jumps in and takes over execution after the first behavior in HearAJoke. After TellOneJoke finishes, I see the second behavior of HearAJoke, then the second behavior again, continuing on through the BT. Very odd.

I’ve tried to make sure I’ve removed everything asynchronous that could be happening in that first Behavior, making the entire path-making process conditional on it not already existing, then sending it in as an argument to the subtree to make sure it already exists, so that first execute script is basically just doing console statements and checking a conditional now. I don’t see how it could be delaying enough to cause TellOneJoke to kick off, and anyway, should the Sequence be forcing these to act synchronously?

Hello Chris,

I have been doing some more digging into this and have found (similar to what it sound like you did) a more boiled down way to reproduce the behavior you have been seeing.

It definitely looks like something unexpected is happening here and I am working with the team to get to the bottom of it.

As you pointed out, if you create a looping .bt with multiple subtrees the second loop will skip behaviors in some of the subtrees. Upon further testing I have seen that subsequent repeats of the loop (so when the sequence is looped a third, fourth etc. time) the behaviors will execute out of order.

As I mentioned, I have made sure the team is aware of this behavior and I am working with them to get to the bottom of this soon!

On an different note, I wanted to update you on MIMs like the ones your skill uses let you know that we have taken down the sample code and video about MIMs from our documentation.

The reason for this is that we have decided not to have MIMs as they existed in those samples be part of the SDK. We are working on including a dedicated MIM behavior in the SDK that will serve a purpose like the MIMs in that sample code but will likely look very different and be a bit easier to use.

I wanted to let you know this because, while you are more than welcome to continue to use code like the MIMs, they will not be directly supported in that format going forward.

John,

Thanks for the follow up. For what it’s worth, I’ve been able to verify that, for the times by BTs skip, its exactly every other time, after the first, so every even time.

I figured something was up with MIMs. No worries. I understand everything early access is subject to change. I’ll just change when it changes. I learned a little technique along the way, so not a loss in my book.

I have just confirmed this error in one of my skills as well. You can download the code for that here: Jibo, Look Away

In this skill, a subtree is referenced with a TimeoutSucceedJs decorator on the subtree’s initial sequence which is set by an amount passed in via the notepad. In controlled experiment, I ran the skill 10 times with the exact same input, passing the subtree’s TimeoutSucceedJs a 30000ms (30 sec.) parameter. It ran fine the 1st, 3rd, 5th, 7th, and 9th times. On every other (even) run, the subtree’s TimeoutSucceedJs succeeded immediately as if I passed it 0ms. Interestingly enough, with a console.log I confirmed that the TimeoutSucceedJs was passed 30000 each time, so the issue is very likely the subtree returning prematurely, not the TimeoutSucceedJs.

If you would like me to prepare a boiled down version of this issue for review, just let me know. Otherwise, I just wanted to confirm that this bug does exist and that you can see it in action currently in the skill I reference above.

@Admin.JiboSupport: Just wanted to check in and see if any progress has been made in fixing this issue yet. I have this bug appearing in another one of my skills (the one I mentioned above and a second one), so a fix would be greatly appreciated.

I have found that adding a TimeoutJS of 1000ms at the end of the subtree seems to help in some situations strangely enough which I’m using as a partial workaround in the meantime.

1 Like

Hi Michael,

Thanks for checking in about this! We have made headway on this issue and we currently expect the fix for it to be included in the next update to the SDK.

Thanks again,
-John

2 Likes

Thanks, John. That’s great news!

I just updated the knock knock jokes, and sure enough, the issue went away. Thanks to the SDK team and @Admin.JiboSupport for the follow-up!