here is the problem: how must I read/interpret this section? Sorry if that is explained somewhere else. I looked into the doc and the forums and wasn't able to find a place where it was explained (I'm sure it exists though, hence the apologies here!).
Also, what may cause this one of many instances of this one custom app be the only one to have that problem? That part totally escapes me. I've run tests on the app in questions and all its functions seem to start and end within millis. Could it be a sort of overstacking of scheduled tasks that are missing a condition to stop somewhere? Any idea is welcome.
There really isn't any such place, as each app or driver implements this in its own way, and the details are thus particular to that app or device. The details are often useful only to the developer, with the main thing for end users being maybe to be suspicious of long-running jobs. You certainly seem to have a few!
I can tell that the first one is the Sonos Integration, which is quite likely the built-in option (I'm not aware of any others). I just checked my hub and don't see this job, and I'd immediately be suspicious of anything running for that long. You might want to take a hub backup, download it, and then restore it. This should "clean" your hub database and eliminate corruption as a possible culprit for these oddities. (You'll often see the advice to do a soft reset in before the restore; this doesn't hurt as long as it's the only reset you do, not the radios, but it's no longer necessary — assuming you can get to the regular hub interface do just do the restore, which you can.)
If this doesn't help, perhaps support staff would be interested in looking deeper at your hub. It might also be good to know what that second app or driver really is (clicking the name should open the actual app or device and let you see if you don't know for sure).
Thank you! The second app is an app of my own that I use for many other rooms and locations. The oddity in question is that it's only that very instance that seems to show in this "running jobs" section - ever odder is the fact that it does it again after deleting the instance an recreating it with the same devices at play (it's a motion sensor lighting app)...
What I am trying to understand is what it means when it shows "running for XXX seconds" because when I look at the logs and run this very app's instance methods/functions several times it all appear as if the app was working properly. In other words I don't understand what this console is telling me: what is stuck for XXX seconds? Could it be, for instance, a request made to a device that never returned its value? Makes no sense because this is not managed at the app's level... is it? @staff might be able to show me the way toward some documentation that they most likely wrote somewhere about this: what "running job" is actually running? Does it mean it's stuck in a sort of infinite loop?
I wrote (most of) the documentation and wouldn't be surprised if the above is more than you'll find there given how particular these details are to any specific situation.
This means that some scheduled job your app (or driver) is running started by never ended. Unless you see a reason in your code that this should happen (and even then, I'm not sure anything as long as all of these is good...), then there could be something else going on. That is why I suggested database corruption as one possibilty, with restore being one way to address that. I would start there before doing any more troubleshooting--it could be that simple.
I see. So there's no way to truly narrow it down to what's really actually going on, it seems. I have tried database restore but, basically, after each major firmware update, this happens and it is getting problematic. I wish I had more time and, most of all, tools at my disposal to try and troubleshoot this.
