Concurrent Synchronous Plugin Actions

[joaomgcd]

Hi Pent.

I've just hit an issue with AutoWear that may be an issue with the synchronous protocol, but correct me if I'm wrong. It seems that when there's concurrency, only 1 synchronous action will proceed. This is the use case I have:

- 2 profiles that trigger at the same time:

Profile: Synchronous Test 1 (457)

State: AutoWear State [ Configuration:Connected: true ]

Enter: Connected Confirm (458)

A1: AutoWear Confirm Screen [ Configuration: Timeout (Seconds):20 ] 

A2: Flash [ Text:Confirm %awmessage Long:Off ] 

Profile: Synchronous Test 2 (624)

State: AutoWear State [ Configuration:Connected: true ]

Enter: Connected Battery (625)

A1: Wait [ MS:0 Seconds:3 Minutes:0 Hours:0 Days:0 ] 

A2: AutoWear App [ Configuration: Timeout (Seconds):60 ] 

A3: Flash [ Text:Battery %awmessage Long:Off ] 

- In Profile 1, screen comes up and waits 5 seconds for user interaction. Task is synchronously waiting in A1 for 5 seconds

- In profile 2, it waits 3 seconds then executes a command that proceeds right away

This is what happens:

- 2 profiles trigger

- Profile 1 A1 waits

- Profile 2 A2 synchrounsly runs after 3 second wait

- Profile 1 A1 never proceeds and times out: this is the issue

I've added the line

                        Log.v(TAG, "Signaling Finish: " + completionIntent.toUri(Intent.URI_INTENT_SCHEME));

in TaskerPlugin.java right after

                        completionIntent.putExtra(EXTRA_VARIABLES_BUNDLE, vars);

and this is what appeared:

03-17 11:00:10.550  17254-17882/com.joaomgcd.autowear V/TaskerPlugin﹕ Signaling Finish: intent:2#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;i.net.dinglisch.android.tasker.extras.RESULT_CODE=-1;end

03-17 11:00:10.677  17254-17847/com.joaomgcd.autowear V/TaskerPlugin﹕ Signaling Finish: intent:2#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;i.net.dinglisch.android.tasker.extras.RESULT_CODE=-1;end

It seems that there is no distinction between the 2 "signalFinish" so Tasker just runs the latest one?

Hope this makes sense to you :)

Thanks as always

João

[Pent]

I've just hit an issue with AutoWear that may be an issue with the synchronous protocol, but correct me if I'm wrong. It seems that when there's concurrency, only 1 synchronous action will proceed.

That shouldn't be the case.
 

- Profile 1 A1 waits

- Profile 2 A2 synchrounsly runs after 3 second wait

- Profile 1 A1 never proceeds and times out: this is the issue

 

03-17 11:00:10.550  17254-17882/com.joaomgcd.autowear V/TaskerPlugin﹕ Signaling Finish: intent:2#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;i.net.dinglisch.android.tasker.extras.RESULT_CODE=-1;end

03-17 11:00:10.677  17254-17847/com.joaomgcd.autowear V/TaskerPlugin﹕ Signaling Finish: intent:2#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;i.net.dinglisch.android.tasker.extras.RESULT_CODE=-1;end

 

It seems that there is no distinction between the 2 "signalFinish" so Tasker just runs the latest one?

Tasker adds an ID to the data of the intent actionid:AN-INTEGER-HERE so I think that will only
be the problem if it's getting dropped somewhere. I don't see it in your log lines above, only
the actionid part.  Could you please try looking specifically at the
intent data to see if that's happening.

Are you using the original intent that came from the host to the receiver as the intent in
signalFinish ?

Note that there's an argument in signalFinish for the variables, you shouldn't be adding
them directly to the bundle if I remember right.

Pent

[Pent]

I've just hit an issue with AutoWear that may be an issue with the synchronous protocol, but correct me if I'm wrong. It seems that when there's concurrency, only 1 synchronous action will proceed.

That shouldn't be the case.
 

- Profile 1 A1 waits

- Profile 2 A2 synchrounsly runs after 3 second wait

- Profile 1 A1 never proceeds and times out: this is the issue

03-17 11:00:10.550  17254-17882/com.joaomgcd.autowear V/TaskerPlugin﹕ Signaling Finish: intent:2#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;i.net.dinglisch.android.tasker.extras.RESULT_CODE=-1;end

03-17 11:00:10.677  17254-17847/com.joaomgcd.autowear V/TaskerPlugin﹕ Signaling Finish: intent:2#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;i.net.dinglisch.android.tasker.extras.RESULT_CODE=-1;end

 

It seems that there is no distinction between the 2 "signalFinish" so Tasker just runs the latest one?

[João Dias]

Thanks for the response.

Ok, I put a breakpoint in the first line of my Tasker BroadcastReceiver and when I do

intent.getStringExtra("net.dinglisch.android.tasker.extras.COMPLETION_INTENT")

this is what I get

intent:16#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;end

It seems that the scheme is still just "actionid" even when looking at your original intent.

so it should be 

scheme=actionid:3

for example?

Thanks again.

--
You received this message because you are subscribed to the Google Groups "Tasker - Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taskerdev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pent]

intent.getStringExtra("net.dinglisch.android.tasker.extras.COMPLETION_INTENT")

this is what I get

intent:16#Intent;scheme=actionid;action=net.dinglisch.android.tasker.ACTION_PLUGIN_FINISHED;component=net.dinglisch.android.taskerm/.ReceiverStaticAlwaysOn;end

It seems that the scheme is still just "actionid" even when looking at your original intent.

Yeah, but if you do Intent.parse( uri, Intent.URI_INTENT_SCHEME ).getDataString() on that, you'll get actionID:16

Pent

[João Dias]

Oh, right I wasn't aware that the number after intent: belonged to the data :) Thanks!

Yeah, turned out I was overwriting a value every time I received a new request, so that's why I ended up always using the last value for every action! Fixed now!

Thank you very much for your help and for helping me fix my mess ups :)

Thanks again

João

--

[Pent]

Glad you could find it.

Pent