Issue with autostart after phone launch (boot)

[F.]

I noticed a glitch when auto-restarting of flows is enabled in the main app settings. 

In most of my flows I use separate fibers to detect sensor changes (e.g. when wifi connected) and those give that information to the main fiber which will process that information. To synchronize both fibers, I use variable give / take blocks - the sensor flow gives variables to the main fiber, after taking them the main fiber gives a variable back to the sensor fiber so that it "knows" the main fiber got the information.

However, after launching the phone all fibers were restarted but resumed their work at the spot where they were in their execution. In my case the two different fibers ended up waiting for variables from each other which is never the case during execution after a dedicated manual start of the flow. It seems the internal queue of "messages" containing the given/taken variables has not been restored correctly.

So far I was not aware of that fibers continue their execution at the same spot when they are "stopped" caused by shutting down the phone. It seems to me that simply resuming the fibers regardless of their "implementation" might be a bit fragile. I would rather want them to restart but through the regular start block of the flow. In my eyes it would be a neat option settable in the flow start block if the flow should continue its work at the current spot or with the flow start block when it is restarted after a phone reboot.

What do you think?

[Henrik "The Developer" Lindqvist]

After reboot fibers should resume where they were, not restart: https://llamalab.com/automate/doc/flow.html

If a fiber resumes at a Variables take block then it will immediately take a "message" from its queue, unless it's empty of course. The queue is persisted "inside" the fiber, so i'd doubt there's an issue with it being restored.

Ensure the fibers aren't stuck in some state, waiting for a change that won't occur because the device rebooted.

Fiber being persisted and resumed was implemented that way because the system can kill an app at any time, then restart/resume it, e.g. in a temporary low-memory situation, and from an app perspective there's no good way to tell that apart from a device reboot.

If you wish a fiber to restart, then fork of a "monitor" fiber that use the Broadcast receive block with action Boot completed to await a reboot restart, followed by an Fiber stop and new fork, loop or Flow start.

An option to not resume a fiber is a feature on the to-do list, but i'm not sure it would be possible to implement reliably, as said it's difficult, maybe impossible, to an app kill vs a reboot apart.

[F.]

Thanks for the explanation. I understand the idea with the work-around and consider to implement it, thanks for that. 

But I'm also interested in getting the initial issue solved. What could I do to help finding the root cause for the deadlock in my 
flows? The regular log shows only that the fibers have been resumed, not more. There is nothing logged about the message queues.

So you say that there is no difference in switching the phone off vs. killing the Automate app on purpose? So I could easily reproduce the issue many times. 

[Henrik "The Developer" Lindqvist]

Are the Variables take block using proceed "Immediately" or "When available"?

Using the former is likely more prone deadlocks.

Do every fiber log "Variable take" after the "resumed after restart"?

If not, then its likely some other issue.

Yes, from Automates perspective there's no difference, so you could use "Force close" to debug.

[F.]

The "Take" blocks wait until variables are available. I guess it has something to do with one of the "sensor" blocks. E.g. the "Wifi connected" 

block sometimes recognizes the disconnect forced by the shutdown of the phone. Then the fiber tries to give the variables to the process fiber. 

which might or might not waiting for them to be taken at that exact moment in time. So far I was not able to replicate the misbehavior by just killing Automate. And it seem to happen after the reboot rarely too. I leave the logging enabled and if it happens again I will share the logs. Unfortunately the flow is quite complex. I don't know if you have the time to review it. I have upload it to the community: 

https://llamalab.com/automate/community/flows/43252

[Henrik "The Developer" Lindqvist]

Indeed, the flow is far to complex for me to debug.

Try making a simple one, with just few "sensor" blocks/fibers "giving" anything without complex processing, and a take block simply logging when it gets a message, that can reproduce the issue, to deduce if it's really caused by the Variable give/take blocks.