Automagic Forum

Hi.

Been using AM for a few months now. Quite an amazing app. Congrats.
I did a quick search on this topic but found no results.
I've been editing flows to make them more complex and found that if I put a confirmation dialog condition, it will halt other separate branches that should continue on their own. The flow waits at the same "step level" of the confirmation dialog condition:
Say the flow has two branches after a true condition. In Branch1, the next step is the confirmation dialog (with a 1m timeout) and then some other stuff. Branch2 has other actions that don't require user intervention. The thing is, Branch2 will wait at the same step of Branch1 where the confirmation is placed, be it step 1, 2 or 3 after the main true condition.

Is this by design? Shouldn't other parts of the flow continue regardless of the confirmation dialog?
Thanks in advance.
Best regards.

I tested with confirmation dialog with timeout and another action at the same level, also after a true condition (another confirmation dialog). Tested with notification on screen, notification on status bar, set wifi state on/off, all of them executed immediately even I don't answer yes no to the confirmation dialg. Even tested with input dialog, but input dialog always appear first no matter where I drag it (as long as still same level branch).

What is your branch2 action/condition? So I can test the same to see if same thing happen. Most likely the elements in branch2 has something to do with I/O (file read/write)

Hi.
Thanks for taking a time to look into this.
Please find a test flow and screenshot attached. Forgot to remove the timeout in the first confirmation dialog. When I run this, the second confirmation dialog stops the whole flow until yes or no are selected. The notification on screen "Step 1" appears and then nothing until you select one option. This happens at least on my phone.

Best regards.

I get it now. You mean the action after the first level (second level). I thought it is the first level. So 1st level of one branch can halt the 2nd level of the other branch.

It seems to be by design. Even if you remove the first confirmation dialog and branch the trigger directly to the second confirmation dialog and notification step 1, the vibrate still waiting for the confirm dialog.
So whenever there is parallel execution, automagic will wait till every branch finish first from the number of elements executed.

I tested it with loop, it will count the number of elements executed. So the left branch can halt the loop as well (if there is any). You should redesign your flow so it will be executed in series. As I stated in my thread about parallel style, that it will cause a lot of logic problem. Use it sparely, only when needed. You don't want your 3rd step halted by the 2nd step confirmation dialog at the other branch. You can parallel it, but just single level, or max 2 level if you know the first level of other branch won't halt the progress.

So far I only use parallel for multiple choice. If you really need to parallel it out, maybe you should try to put the branch that need to be executed without interruption at another separate flow. Then use action execute flow at the branch, it will executed immediately. So it will run in another flow and not disturbing current main flow logic. I haven't try it out, because the result probably can be different for every case.

Hi.
Thanks again.

Desmanto wrote:... It seems to be by design. Even if you remove the first confirmation dialog and branch the trigger directly to the second confirmation dialog and notification step 1, the vibrate still waiting for the confirm dialog.

I would like to understand the logic or limitation of this implementation (maybe it is an Android limitation, don't know). My first assumption was that there might be a bug in the Confirmation Dialog that would cause the whole flow to wait until user intervention, because the logic of the flow says otherwise.

Desmanto wrote: So whenever there is parallel execution, automagic will wait till every branch finish first from the number of elements executed.

Actually, in this case, only the dialog stops the flow. There could be more steps in any of the branches and it'll stop and wait. Left branch could include several more steps before the dialog allowing the right branch to finish, so there must be something else in the way flows are executed.

Desmanto wrote: I tested it with loop, it will count the number of elements executed. So the left branch can halt the loop as well (if there is any). You should redesign your flow so it will be executed in series. As I stated in my thread about parallel style, that it will cause a lot of logic problem. Use it sparely, only when needed. You don't want your 3rd step halted by the 2nd step confirmation dialog at the other branch. You can parallel it, but just single level, or max 2 level if you know the first level of other branch won't halt the progress.

Yep. I read that one after posting this. In many cases, parallel execution is way more efficient, and in cases like this one, a must if you wanted to keep a single flow that runs some actions while others have user intervention.

Desmanto wrote: So far I only use parallel for multiple choice. If you really need to parallel it out, maybe you should try to put the branch that need to be executed without interruption at another separate flow. Then use action execute flow at the branch, it will executed immediately. So it will run in another flow and not disturbing current main flow logic. I haven't try it out, because the result probably can be different for every case.

In the real flow, after the confirmation dialog, there's a Set Flow State action that turns on another flow that monitors battery level. I know I can change the design. The problem with moving the right branch to another flow is that the action running that new flow would have to be before any confirmation dialogs (from the same flow) or it won't run. I can move the dialog out of this flow, but the logic of the whole thing would need to change quite a bit.
This is why I'm asking about whether this is a bug or how it is supposed to work.

Thanks.

Hi,

This is indeed by design to make flows execute more predictably which means that executing a flow multiple times with the same input ensures that all actions of all branches execute in the same order again and that not one branch of a flow is executed so fast that another branch does not get a chance to run. I have an item on the list of features under consideration for a new option for a flow to disable this feature so that each branch executes as fast as possible.

You can work around this feature/limitation by placing one of the branches in a different flow that is executed by an action Execute Flows.

Regards,
Martin

Martin,

Thank you very much for the explanation. There was indeed a reason for this behavior. I now completely understand the logic behind the way this works. Still, I think it is not a matter of speed for each parallel branch, if whether one side finishes faster than the other, but the result of the complete instructions automated with the flow.

Anyway, this is not any kind of deal breaker; it is just something to keep in mind when doing this kind of flow. I assume (because I haven't tested) that there are other actions that would cause the same thing (such as sleep, which pauses the whole flow even though it might be placed in one branch).

I can see several options to bypass this, moving some parts to other flows being one of them. A feature to execute parallel branches based on their pure logic would be an awesome addition IMHO.

Thank you for your time and great support.
Best regards.

@iarvi : So it has been confirmed by Martin, that it is by design. I would also prefer this way, so no logic flaw if one execute faster because of the timeout. Actually there are a lot of action/condition that has the ability to halt flow just like confirm dialog. Speech output will also halt the flow until the whole text has been finish. Execute command, HTTP request, where there is progress and timeout will also halt the flow. Bluetooth LE Device available, Init variable location, read file/write to file; there are still many.

Parallel style should be use carefully. I still prefer to use it only when there is just one action or in multiple choices.

Separating to another flow will require redesign for the whole flow (especially when there is variable involved). But seems to be the only solution for the parallel style branching. Just compare it, do the parallel style worth the time for redesign to a separate flow? Or it is better to just keep them in series and in the same flow?

Flow separation is better choice if you started to have a quite complex flow (let say more than 25 elements). I tried to download the basic tool from the flow sharing section. The flow is so gigantic that my phone lags when dragging around. It would be better to separate it to 5-10 flows rather than combining them into a single one.


@Martin : I think Iarvi want some way to allow that single element to be executed separately from the main logic.

In tasker, at some action such as "Say" (equivalent to Speech Output), there is additional option "Continue Task Immediately". If this is checked, then the task will directly continue to the next action while the speech is still being spoken out. I think, under the hood, when this is checked, that "Say" action will be executed in separate thread/process, so it doesn't interrupt the main task flow. Similiar to putting it to separate flow with only just one action.

Automate also has something called "Fork", starting a new fiber (running flow) inside a running flow. Where that fork branch will execute on its own logic. I don't have much experience with it, only testing for a while. But I think it is the same concept, executing that action in separate thread/process.

So if there is additional option in Automagic to "continue immediately" for action/condition that has the halting power (or timeout), we can use it to control the way the flow executes. I agree to separate the branch flow so it doesn't interrupt the main logic. But at some occassion where the branch is only single action, we still wanna continue the main flow.

Example : we can make flow speaking some tutorial or welcome greeting; while at the background, the main flow is downloading some data, parse it and output the result. By the time the speech finish, the data has been parsed already and ready to be output to the screen. If the main flow is waiting for the speech output to finish first, then it will take some additional time for the processing again. If we separate it to another flow, that flow will be one trick pony, just contain a single action (speech output). And another problem for separate flow is the variable passing should go thru GloVar (inter flow), which make it slower.

So far I am good with current flow concept. If it is going to be implemented, This "Continue flow immediately" must be properly planned. When I research about automate, several comments stated that the fork can cause chaos or logical loop if not designed properly. So maybe start from small first, example try only that speech output first. But I think adding this will require to revamp the whole execution concept of the flow. I will prefer a stable flow execution rather than implementing something that will break so many other things.