Timeout Issue with Automate

[termux]

Timeout Issue with Automate

[agnostic-apollo]

Termux:Tasker only "requests" a default timeout, which is now 10s for all cases in version 0.5. Check number 9 in Issue 36 for details. The user can still override it from the plugin host side, even though commands themselves are not directly affected by any timeout set. Automate app was however considering it as a literal timeout instead of a request, but has provided a Ignore Timeout option in version 1.23.1.

So this issue should be considered as solved, even though a "no timeout" can be sent back only in the case if plugin action is being configured by the Automate app, if the devs and users think that would be better. Would this be the value 0? Although, the Tasker way IMO is better since it provides the user more control, specially with Continue Task Immediately behaviour.

Automate app should also request the permission com.termux.permission.RUN_COMMAND for the plugin to work in version >= 0.5. Check the updated README for more information.

[Archenoth]

Hihi! I'm the one who put that default there, and while I'm not sure how to set it from Automate, there is indeed an option for setting the timeouts in Tasker~ (10 seconds is just the default value the plugin suggests initially--so don't worry, it's not a hardcoded limit!)

The reason for a 10 second default was because most actions are pretty quick--and if something took that long, it was just less annoying to let someone set that time to a bigger number rather than force someone to wait longer if they accidentally did something that would never stop.

This post was made too long ago for me to reply, and I'm not really affiliated with Tasker or anyone else that can change how this all works, but the suggested timeout from the plugin should be in the net.dinglisch.android.tasker.extras.REQUESTED_TIMEOUT extra in the intent sent to Tasker after configuration. (After which, you have the ability to override it in Tasker itself--but if you can't override it in Automate, then perhaps you have the ability to at least change that extra before it gets there)

And speaking of:

I don't know why they think the hostSupportsSynchronousExecution flags requires a timeout, maybe that's some Tasker limitation, the plug-in API is so poorly documented.

The reason I put that there is because it doesn't make sense to wait for the result of an asynchronous task; halting the task and waiting for the results of the script is what "synchronous" means in this case.

Basically, having no timeout on a Tasker action makes it asynchronous, and in termux-tasker's case that means it won't ever kill the resulting process (Because it doesn't need to, since it's not holding up the task)--but it also means you can't use the exit status or output in subsequent actions since you will probably run them before your script can finish.

This is explained in the comment above the code they linked:

termux-tasker/app/src/main/java/com/termux/tasker/EditConfigurationActivity.java

Lines 155 to 161 in 27b442d

	// To use variables, we can't have a timeout of 0, but if someone doesn't pay
	// attention to this and runs a task that never ends, 10 seconds seems like a
	// reasonable timeout. If they need more time, or want this to run entirely
	// asynchronously, that can be set
	if (TaskerPlugin.Setting.hostSupportsSynchronousExecution(getIntent().getExtras())) {
	TaskerPlugin.Setting.requestTimeoutMS(resultIntent, 10000);
	}

[KevWal]

Thank you for getting back to me on this one. I still have the issue so will take a look through your sugestions tomorrow. Cheers Kevin

…

On 9 November 2020 20:47:02 GMT, Archenoth ***@***.***> wrote: Hihi! I'm the one who put that default there, and while I'm not sure how to set it from Automate, there is indeed an option for setting the timeouts in Tasker~ (10 seconds is just the default value the plugin suggests initially--so don't worry, it's not a hardcoded limit!)  The reason for a 10 second default was because most actions are pretty quick--and if something took that long, it was just less annoying to let someone set that time to a bigger number rather than force someone to wait longer if they accidentally did something that would never stop. [This post is was made too long ago for me to reply to](https://old.reddit.com/r/AutomateUser/comments/erthy2/automate_termux_timeout_issue/ff7vbnx/), and I'm not really affiliated with Tasker or anyone else that can change how this all works, but the suggested timeout from the plugin should be in the `net.dinglisch.android.tasker.extras.REQUESTED_TIMEOUT` extra in the intent sent to Tasker after configuration. (After which, you have the ability to override it in Tasker itself--but if you can't override it in Automate, then perhaps you have the ability to at least change that extra before it gets there) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #33 (comment)

-- Sent from my Android device. Please excuse my brevity.

[Archenoth]

Hey! Happy to help!

And sorry for the extremely long delay--I'm not actually part of the core Termux team or anything, so it was just kinda random chance that I saw this issue. But yeah! I don't think the issue is a plugin one.

Tasker plugins suggest default values for things that are configured in Tasker itself--and timeout just happens to be one of those options.

If you'd like a stop-gap fix in the meantime, if Automate can run based on received intents, you could make your script fork into a background process. Then, when it finishes, have it run:

am broadcast -a net.dinglish.tasker.continue

And then listen for that in your task continuation and continue!

---

For a more permanent solution, I would recommend suggesting a feature request for Automate to allow configuring the suggested values that plugins return for things like timeout.

You can even include a link to this issue, since it has some information that might be handy for handling Tasker plugins--since I imagine this might be an issue for others as well!

I hope this helps, and good luck..! ^^

[agnostic-apollo]

Since no default timeout for Automate has been suggested, closing this.

Related fecba50