Possibility to change listener & openfaas timeout as an app developer

[jonas-martinez]

Currently there is a 5 or 10 seconds timeout on listeners. This can be a problem because some apps might do some time expansive listeners and trigger this timeout.
We also do not want to give too much time for the listeners because they might consume a lot of time because of an infinite loop.

It could be a good idea to let the developer choose what timeout he wants to give to the listeners based on his app. If it is a basic app with no time consuming tasks, he might choose a 1 or 2 sec timeout. If the app contains time consuming listeners he might choose 1 hour or more for the timeout.

[jonas-martinez]

@lenra-io/devs

[shiipou]

I think it's better not to allow it for application developers. They have to do asynchronous listener. That is, return a UI to give the loading feedback, and then modify the data to display the desired UI after the long loading time.

[taorepoara]

It was true in hold Lenra version but now the UI is rebuilt when the listeners change the data. So a listener can dispatch UI rebuild asynchronously.
The UI views should be built faster (that's true), but I don't think that Lenra should define a timeout that stop UI rendering, since it could be even worst for user than waiting a little for the UI.
We could alert the app creator when views are taking to much time to respond.

[pichoemr]

@lenra-io/devs
After some tests, we have two ways to manage the timeout.
The first one is to set the exec_timeout value of the watchog, it's very simple:

• put the exec_timeout value in lenra.yml
• it is not necessary to modify the interface or the bdd.
  But the application_runner uses Finch for http requests and Finch does not allow an unlimited timeout (if you set 0, the request is instantly timeout). For the moment I haven't found a way to get over this limitation i continue my research...

The second way is to set the timeout on Finch :

• we need to add the timeout in the environment bdd schema
• probably need a user interface to change/define the timeout value.
• set exec_timeout to 0 on watchog to disable it

[jonas-martinez]

In my opinion the second solution might be better as it separates the timeout handling from the application. This allows the developer to manage his timeout value without deploying a new version of his application.

My only question is what happens if the Finch timeout is triggered ? Does the watchdog cancel the corresponding process or does it keep running and still tries to send back the result ?

[Nesqwik]

We might want to add a global timeout (in the app manifest ?) and allow to specify custom timeout for specific listeners.
As a developer i want to be able to tune the timeout according to my needs. If a listener run should not be longer than 5 sec, i set the timeout to 5s.
If the listener is longer, i can up this timeout to a longer duration.

But generally, most of the listener should never be longer than a few seconds (5s to 10s at most but preferably less than a second).

If we have tasks that are longer, the dev should probably start a background task (thread, process...) and quit the listener function directly. Then this background task can call any number of API on its own.
I think it's already doable right now if i'm not mistaken. To be tested !

[shiipou]

He can't start background job, because the API token will expire when he quit the listener at this time.
But yes, I think that's better to run background job.

[Nesqwik]

He can't start background job, because the API token will expire when he quit the listener at this time. But yes, I think that's better to run background job.

Nope, the token won't expire. It's linked to the session, not to the listener call.
The other issue with background job is the openfaas scaling down/ scaling to that can stop the background task in the middle of its work.
For now we will just set the timeout to infinity (or very long duration). Then we will create a job API and/or customisable timeout directly at runtime (on the app manifest/listener call)