Live/Max hang (Live at 100% CPU) when saving patch

This morning I woke up with a start, "ah, there is one more potential loop in my code" (anyone else have that kind of wake up sometimes? :) .

Let me start with the conclusion: resolving paths with "new LiveAPI(null, path)" was returning non-sensical results.

Details:

• I was running some code in response to the "preview state" (third output) of a "live.thisdevice" going back from 0 to 1 (re-initialising the patch after it was saved).

• This code was using the LiveAPI, but as I mentioned, it turned out that resolving paths (using "new LiveAPI(null, path)") was returning non-sense results; new LiveAPI(null, "this_device") was returning an object of type "Push2" instead of the expected "MaxDevice".

• When I inserted a "deferlow" in between the output of the live.thisdevice and the JS code, I was suddenly getting errors "jsliveapi: Live API is not initialized, use live.thisdevice to determine when initialization is complete".

• From the above my tentative conclusion is that the Live API is temporarily unavailable after a patch is saved, and that getting a "1" from from the "preview state" output of "live.thisdevice" does not mean it is available again.

• Normally, we wait for "live.thisdevice" to output a bang on its first output in order to know that we can use the Live API. Unfortunately, the "live.thisdevice" does not output a bang on that output after a patch is saved.

• I'm therefore not aware of any event I can use to wait for that tells me the LiveAPI is available again after the patch is saved. Right now I'm using a delay 1000 (followed by a deferlow), which seems to work, but it feels a bit brittle.

As for the code that was looping: I hadn't thought about it before because I expect this loop to iterate a few steps at most: it's a loop that looks for the parent of this_device:

exports.deviceTrack = function(path) {
  return function() {
    var parentObj  = null;
    var parentPath = path;

    var i = 0;

    do {
      parentPath = parentPath + " canonical_parent";
      parentObj  = new LiveAPI(null, parentPath);
    } while(parentObj.type !== 'Track' && parentObj.id != 0);

    return parentObj;
  }
}

Here, "path" is usually "this_device"; so this follows the advice from https://docs.cycling74.com/max8/vignettes/live_api_overview#Canonical_Parent and uses "this_device canonical_parent" to find the track that the Max device sits on; except that if that Max device is grouped, the canonical parent is actually the chain of the group, rather than the track, and so we need to continue going higher up to find the track itself.

However, as mentioned above, that "new LiveAPI" was returning non-sensical results; rather than returning the track or a chain, it was running an object of type "Push2", and looking for its canonical parent just returned that very same Push2 object again, ad infinitum.