Please explain: Return Error when priority is not 10

[spiral]

took me a while to find whats wrong here.
Every time I do [perform task] without giving priority to 10 the child task works as expected but throws an error at [return] action (as seen in runlog) and doesn't return the value. If priority is 10 though everything works.
Hope it is clear, tell me if you need the export description.

Could someone please explain whats going on here? Or if this is a bug?

Thank you.

[Richard Davis]

> took me a while to find whats wrong here.
> Every time I do [perform task] without giving priority to 10 the child task works as expected but throws an error at [return] action (as seen in runlog) and doesn't return the value. If priority is 10 though everything works.

I can confirm  this. Just changed one of my perform tasks with a return to priority 10 and got a error....

Rich...

[spiral]

thanks for confirming Rich :)
(I think you meaned you changed it from 10 to something else)

Always using priority 10 as workaround is not the best option as it is blocking until it is ready even if it is not that important in the workflow.

[Richard Davis]

> thanks for confirming Rich :)
> (I think you meaned you changed it from 10 to something else)
>
> Always using priority 10 as workaround is not the best option as it is blocking until it is ready even if it is not that important in the workflow.

Hmmm, don't think we are on the same page..

I have several perform tasks with several different priorities and with return values none of them currently have a priority 10.

I changed one of then to a priority 10 and then I got the error..

Is that your findings??

Rich....

[spiral]

oh thats weird I have the opposite.

Testreturn (190)
A1: Perform Task [ Name:Returner Stop:Off Priority:10 Parameter 1 (%par1):return this Parameter 2 (%par2): Return Value Variable:%returnvalue1 ]
A2: Perform Task [ Name:Returner Stop:Off Priority:7 Parameter 1 (%par1):return this too Parameter 2 (%par2): Return Value Variable:%returnvalue2 ]
A3: Flash [ Text:%returnvalue1
%returnvalue2 Long:Off ]

Returner (193)
A1: Return [ Value:%par1 Stop:On ]


the flash ouput is :
return this
%returnvalue2

If I change priority of second perform task to 10
output is as expected:
return this
return this too

[Richard Davis]

On Nov 10, 2012 9:58 AM, "spiral" <marko....@googlemail.com> wrote:
>
> oh thats weird I have the opposite.
>
> Testreturn (190)
> A1: Perform Task [ Name:Returner Stop:Off Priority:10 Parameter 1 (%par1):return this Parameter 2 (%par2): Return Value Variable:%returnvalue1 ]
> A2: Perform Task [ Name:Returner Stop:Off Priority:7 Parameter 1 (%par1):return this too Parameter 2 (%par2): Return Value Variable:%returnvalue2 ]
> A3: Flash [ Text:%returnvalue1
> %returnvalue2 Long:Off ]
>
> Returner (193)
> A1: Return [ Value:%par1 Stop:On ]
>
>
> the flash ouput is :
> return this
> %returnvalue2
>

OK.. very strange, I just did a similar test as you listed above and got the SAME results...  this will take a little time to figure out the differences in the tasks and I can not do it right now (family time is calling (speaking loudly(yelling)))  but will definitely look into later. 

Rich....

[Richard Davis]

OK... took some looking but here is what I found ..

The reason the lower priorities were working in my other tasks is because it was in a chain of 'perform tasks' so in other words if you take your above test and call it from another task you will still see the error in the run log but you will get the return value.. 

Hope that makes sense .....

Let me know if it works on your end...    Rich..

[Richard Davis]

I just found this in the user guide and assume this new change might be the culprit but I am a little confused on how it SHOULD be working

If I am reading it correctly it would seem that if I want to call a task t2 from task t1 that has been started from a profile and would like t2 to finish before t1 continues then 1 would have to  deselecting Enforce Task Order for that profile.  Correct?

Same-Profile Tasks

Tasks from the same profile (including any sub-tasks started via Perform Task) by default always execute in the order in which they are launched. Other tasks from the same profile remain completely inactive until any previous profile is complete. The main purpose of this rule is to correctly handle rapid changes in a profile's activation state.

This behaviour can be disabled by deselecting Enforce Task Order in the Profile Properties dialog.

Rich.....

[spiral]

Hey Rich thanks for trying to debug this further.

"in other words if you take your above test and call it from another task you will still see the error in the run log but you will get the return value.."

that is something that I observed too, but couldn't nail down. I sometimes got the value anyway even when the error occurred in the runlog but I did something else I can't remember now :/ but I can confirm that calling from another task works.

and regarding "Same-Profile Tasks" you quoted I don't understand it too but what I think is that we haven't profiles involved at all, in our test case. And that "other tasks from the same profile remain completely inactive" doesn't quite fit in with the error we get AND that the task executes fine until it should return a value.

I guess we are stuck now and maybe only pent could tell whats really going on here or rather what should be going on.

[Richard Davis]

> and regarding "Same-Profile Tasks" you quoted I don't understand it too but what I think is that we haven't profiles involved at all, in our test case. And that "other tasks from the same profile remain completely inactive" doesn't quite fit in with the error we get AND that the task executes fine until it should return a value.

Ah, yes.. definitely strayed off topic... I believe we are definitely discussing a bug here  that pent will be able to confirm and hopefully it will be a simple fix..

I will start another thread with the above question to try to fully understand how the priorities should be working with the perform task. It will make the info easier to find for others in a search as well..

Rich..

[Richard Davis]

Pent, I just wanted to bump this up as I believe spiral has definitely come across a bug as discussed above...

Thanks,    Rich..

[spiral]

 I am sorry to bump this up again, but this error is really a big one for me as it makes using perform task almost unusable.
Just a short message from you pent that you noticed this issue would be appreciated. Thanks.

[Richard Davis]

Maybe 3rd time will be the charm......   :)

Bum,bum,bum,bumbum---- bump /bump

[Rich]

Hmmm, this was not bumping up with regular email. Trying from the
forum on this one..

[Pent]

> *Testreturn* (190)
> A1: Perform Task [ Name:*Returner* Stop:Off Priority:*10* Parameter 1

> (%par1):return this Parameter 2 (%par2): Return Value
> Variable:%returnvalue1 ]

> A2: Perform Task [ Name:*Returner* Stop:Off Priority:*7* Parameter 1

> (%par1):return this too Parameter 2 (%par2): Return Value
> Variable:%returnvalue2 ]
> A3: Flash [ Text:%returnvalue1
> %returnvalue2 Long:Off ]
>

> *Returner* (193)

> A1: Return [ Value:%par1 Stop:On ]
>
> the flash ouput is :

> *return this
> %returnvalue2*

You're running the task with the test button, right ? Then the parent
task has a priority of 10 and and so the task launched with A2 doesn't
run until the parent has finished. If A2 uses priority 10, then it
finishes before the parent task because Tasker gives preference to sub-
tasks if two tasks have the same priority.

Pent

[Pent]

p.s. thanks for the external bump Richard :-)

Pent

[Richard Davis]

> You're running the task with the test button, right ?

Ummm,  yup...   :)

Then the parent
> task has a priority of 10

Damm, I actually knew that..

and so the task launched with A2 doesn't
> run until the parent has finished. If A2 uses priority 10, then it
> finishes before the parent task because Tasker gives preference to sub-
> tasks if two tasks have the same priority.
>

As usual Pent quite correct.....    :)

OK...  re-tested and everything works as it should however it does show the errors in the run log as spiral reported ( it will be interesting to see if he was using the same faulty  test procedure). I have posted the run log of my test below.

I'm assuming that since  everything is working correctly these errors can be ignored?

Thanks for the reply Pent, Sorry about the false bug report.   :(

Rich....

[Richard Davis]

Oops forgot the log....

20121115 16.53.01 P Inactive ID337    Return Test
20121115 16.53.12 P Active   ID337    Return Test
20121115 16.53.12 T Running  ID338    Task Send
20121115 16.53.13 A OK       ID338.1  Task Send.Perform Task
20121115 16.53.13 T Running  ID339:2  Returner
20121115 16.53.13 A OK       ID339:2.1 Returner.Variable Set
20121115 16.53.13 A Err      ID339:2.2 Returner.Return
20121115 16.53.13 T ExitErr  ID339:2  Returner
20121115 16.53.13 A OK       ID338.2  Task Send.Flash
20121115 16.53.13 T ExitOK   ID338    Task Send

[Pent]

> I'm assuming that since  everything is working correctly these errors can
> be ignored?

Actually, the Run Log doesn't seem to fit with my nice story since the
Send task is still running when the Return action takes place so I
don't see why it should error.

Will have to test it myself I think.

Pent

[Marko Pahlke]

Thanks for testing and bumping Rich. And thanks Pent for responding. I just didn't reply yet because I have no time logging into groups from my pc to respond as spiral.

But back to topic, your explanation seemed logical but even with this in mind I couldn't, other than Richard, understand why it acts the way it does. Take for example the conclusion from before that if you put another parent before the task that calls the responding task it works. According to your explanation it shouldn't work neither, because as you said child tasks have higher priority if called with the same priority as the executing task. So it does essentially not matter if you put an extra task before or not. But it acts clearly differentially.
And another thing according to your explanation the calling task should exit before the child can respond and hence the error but it does not if you look into run log. Everything works as expected until return action.
But I was still not able to nail the issue down to something concrete. For me it seems as if priorities aren't respected everytime the run log always seems a little different than what I would expect even after very carefully tuning priorities.

Thanks for testing pent.
Spiral

[Richard Davis]

> But back to topic, your explanation seemed logical but even with this in mind I couldn't, other than Richard, understand why it acts the way it does. Take for example the conclusion from before that if you put another parent before the task that calls the responding task it works. According to your explanation it shouldn't work neither, because as you said child tasks have higher priority if called with the same priority as the executing task. So it does essentially not matter if you put an extra task before or not.

'I think' pents logic does work here (assuming we are still using the test button), because now the original task (the test button) has priority 10 so that will finish first but now you have made the first called task a lower priority by defining it in the perform task action. So now things work as they should with respect priorities.  In my test I took the test button out of the equation and fired the tasks with a profile and i believe everything worked as it should with exception of the errors which did not seem to affect the expected behavior. 

Does that sound correct??

Rich..

[Pent]

There's a bug with the Return action, if you have Stop checked, it
stops with an error instead of with an OK. Have fixed for next update,
sorry for all the problems caused.

Pent

[Marko Pahlke]

Thanks Pent. Does this error affect the resuming of the parent? Or is it just a cosmetic change.

Rich you are right I think.

Waiting for the next version (or beta first?)

Thanks again.

[Pent]

> Thanks Pent. Does this error affect the resuming of the parent? Or is it
> just a cosmetic change.

It's just cosmetic.

Pent