Add support for concurrent / parallel requests

[cipriancraciun]

Is your feature request related to a problem? Please describe.

Sometimes a shortcut can take a long time to execute (for example the server is processing something, or is waiting for external resources).

Thus, while waiting for the long shortcut to execute, the user initiates other shortcuts (that could for example execute immediately), these aren't executed concurrently with each-other, they are queued and executed one-by-one.

This means increased waiting times for the user.

(This is not related with #397, which tackles the subject of concurrent requests issued from the same parent multi-shortcut. Here I'm referring to independent top-level shortcuts.)

Describe the solution you'd like

Issue each shortcut request independently of each-other. Perhaps impose a global concurrency limit (say 8-16).

Describe alternatives you've considered

I don't see how using the current tool one can achieve this concurrency.

[Waboodoo]

Hi,

This is (somewhat) already possible. When editing your shortcut, go to "Trigger & Execution Settings" and set "Execution Mode" to "Run in background". Shortcuts that run in the background can run partially in parallel, in the sense that one shortcut waiting for a response won't block another from getting started.

There is also the concept of "headless execution", which automatically applies to very simple shortcuts (see https://http-shortcuts.rmy.ch/advanced#headless-mode for how to use it). Shortcuts in headless mode will also not block other shortcuts from getting started.

Would either of these approaches work for your usecase?

[cipriancraciun]

I remember trying Run in background a few months ago, but from what I remember, these types of shortcuts don't support getting access to the clipboard. With regard to "headless" shortcuts these don't work because I have a post JS script that uses the response.

---

Perhaps it's better to describe my use-case:

• my shortcuts are split in two: one or more frontends that gathers the required inputs, and a single backend shortcut that actually does the execution and finalizes the task; the frontend passes data to the backend via variables; both are set to run in foreground;
• one of these sets of shortcuts is involved with taking a URL of an article I want to read, passing it via HTTP to a server that uses single-file to archive it, then passes it through a custom build of Mozilla's Readability plugin to extract only the content, etc.; then, the server sends back the URL to the archived and processed file; the shortcut finalizes the task by opening it in a designated browser; (this might take a while, from seconds to a minute perhaps;)
• another shortcut takes a piece of text (mostly from clipboard, or via the share Android feature), passes it via HTTP to a server that uses piper to convert it into an audio file; then the server sends back the URL to the audio file; the shortcut finalizes the task by opening it in a designated audio player; (this usually takes anywhere between 30 seconds to a few minutes;)
• similar to the above, I also have a shortcut (and accompanying server component) that uses Ollama to summarize a piece of selected text, and open the result in a browser; (this usually takes a couple of minutes;)

My usual workflow is as follows: open the RSS reader, see an interesting article, start the archive URL shortcut, move to the next. I can start the save shortcut multiple times, they'll be executed in sequence, which is OK. However, if I find an interesting article, and I want to issue the to audio shortcut, although the two types of processing don't interfere (one is network bound, the other CPU bound), they are waiting one for another. (With summarization it's even worse.)