HTTP Request Trigger: response time

Post your questions and help other users.

Moderator: Martin

Post Reply
Entity
Posts: 1
Joined: 21 Nov 2017 09:29

HTTP Request Trigger: response time

Post by Entity » 21 Nov 2017 21:33

I have a flow, where I use the "HTTP Request" trigger to launch a flow and transmit a few characters of information to the flow.
It all works fine, except the web server listening to the requests only seems to answer once the flow has completed.
Starting another flow with the "start flows" action does not change this behavior, even if "wait for flows to finish" is not checked (the web server waits for both flows to finish before it answers).
If the flow takes longer than a few seconds to complete, or performs actions (like turn of Wifi) that prevent answering the request at the end of the flow, the client sending the request will perceive the server as not responding.

Is there a workaround or a different reason for my problem?
Would it be possible to have the web server respond immediately (possibly via option in the trigger, if there is a scenario where doing so would not be desirable)?

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Re: HTTP Request Trigger: response time

Post by Desmanto » 22 Nov 2017 06:34

I never tested it out until you asked. My flow which use this HTTP trigger is short. So the response is almost instant. It seems to be designed this way or maybe it is a bug (wait for Martin's confirmation). Tested with execute flows also need to wait until the flow finish, regardless the wait option. Tried using Write HTTP response + debug dialog to pause the flow, it still will wait until the I confirm the debug dialog first, before the response is sent back (even though the write HTTP response is executed already!)

For workaround, there are a lot. But I would prefer the Send broadcast/General Broadcast method (look at my index), because it is almost instant. For the flow you need to execute, add another trigger, General broadcast, and put something, example com.automagic.http.helper. Then in the HTTP trigger flow, don't use execute flow, but use Send broadcast, put the same intent, com.automagic.http.helper. Send broadcast is considered an immediate action, so execution is very fast. I tried it already, the response will be sent back even though the other flow is still executing (I pause it using debug dialog too).
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

User avatar
Martin
Posts: 4468
Joined: 09 Nov 2012 14:23

Re: HTTP Request Trigger: response time

Post by Martin » 23 Nov 2017 20:20

Hi,

The trigger HTTP Request waits until the flow ends so all actions Write HTTP Response Text had a chance to write the desired text to the response. An exception is action Write HTTP Response File which writes the HTTP response immediately. You could use the action Write HTTP Response File directly after the trigger to answer the HTTP Request immediately even when the rest of the flow is still running. The file can also be empty if you don't want to return any data at all.
Let me add a distinct action that can be used to finish the HTTP response. Using the action Write HTTP Response File for this purpose is not intuitive at all.

Regards,
Martin

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Re: HTTP Request Trigger: response time

Post by Desmanto » 24 Nov 2017 07:01

Thanks Martin for the confirmation. So it is designed this way, but somehow not effective to some usage. Maybe add a checkbox in the Trigger HTTP Request? Something like "Sent response immediately" ? Or add the checkbox to the action Write HTTP Response?
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

User avatar
Martin
Posts: 4468
Joined: 09 Nov 2012 14:23

Re: HTTP Request Trigger: response time

Post by Martin » 25 Nov 2017 20:10

Yes, adding the checkbox is a good idea. It's probably easier to find than a new action.

Regards,
Martin

Post Reply