Ok, I'm stumped. Need some input from smarter developers than me.
What I'm seeing is that SOMETIMES (not always) on a reboot of my dev hub, another instance of my MQTT app seems to be spawning. Not sure why, or even how really. I wouldn't know how to do that on purpose if I wanted to... lol
I have a debug message that runs in initialize(). On a clean power up of the hub, I see it initialize 1x as expected.
Do a reboot from the interface on the hub, next boot I see initialize() called 2x. Next reboot, 3x. Etc. Until I do a shutdown and pull power.
Anyone see this before? Any tips on how I can track down why it is happening?
What does your Initialize method do? And do you call it from anywhere else, especially if it or a calling function are scheduled for a future execution?
It does the device event subscriptions, a bunch of device property parsing, and then MQTT subscriptions in a driver. I do see the initialize() code complete in all cases (have a debug msg at the end of initialize()), so it definitely is not getting stuck in there.
If I run the method from somewhere else (I can manually trigger it from the driver, or edit the app and re-save) it only runs 1x as expected.
I just refactored the code a bit, which looks like it will work around the issue to some extent. I made initialize just set an atomicState to "initializing" if not already = to that, and schedule the rest of the code that used to run in initialize() in a different method.
I still see initialize() getting hit 2x on a reboot, but the actual init code only gets run once - so it looks like the atomicState check is helping to prevent massive code runaway at least.
I think you're ping ponging on this, from a very quick glance:
if (evt.name == "init") {
initialize()
return;
}
Your app runs initialize. And the driver runs its initialize, which seems to cause an app initialize. If you had more drivers, I suspect it would just grow linearly. Also seems like they're racing-- depending on whether your app has subscribed yet before the driver gets there.
Yup. I completely screwed that up. At least I know what to go fix now....
Thank you @tomw . I would have sworn I checked that... But obviously not. I guess I wasn't as methodical as I thought in my troubleshooting.
It also explains why my workaround - breaking the code into a separate method and using runIn - worked. Initialize still ran multiple times, but the schedules just overwrote each other so the other method only ran once as intended.
