Hi,
I have a test project, which uses Flask’s testing server for now. The only route does substantial processing, which can take more than 60 seconds.
When I run it locally, it works fine. When I run it on Fly, if the processing takes more than 60 seconds the request times out.
Is this a setting that I’ve missed? I didn’t see anything in the docs.
Thanks!
Hey there!
Edit: There isn’t a idle timeout anymore.
There is a 60 idle timeout. If no data is received or sent within 60 seconds, the connection will be closed.
This is not well documented (if at all). We could bring that up a bit, but there are other options that might work for you:
The choice of 60s is pretty arbitrary, we could make 120s work! However, if you ever have a job that takes over 120s, then you’re left with the same problem.
One option I’m really fond of is streaming responses: Streaming Contents — Flask Documentation (1.1.x)
That 60s timeout resets when you send any data at all, so if the work you’re doing can stream data incrementally it lets you run requests as long as necessary.
If you can’t send data incrementally, it’s sometimes worth sending the equivalent of a ping through the stream. SSE handles this for you if it’s an option.
Thank you both. Streaming " " every second before streaming the result JSON then closing the stream worked.
It’d be great to have the idle timeout be configurable.
It’d also be great to have worker VMs that run from a queue and are autoscaled (scaling down when idle). Happy to beta test anything like that which is in the works 
There are limits to the idle timeout we’ll accept, we have to protect host resources (there is a maximum number of open connections we can handle at any given time).
We might be able to bump the timeout up, but it seems like 60s works for most cases!
We could make it configurable to a point, maybe within the range of 0s - 120s. There are some use cases where a lower timeout might be desirable.
Hi @jerome
Would it be possible to configure the idle timeout?
I’m porting a few rails apps which we have not yet changed to stream responses, and having a higher timeout will allow to us to switch while we refractor the apps.
It’s not currently possible. The limit is there to protect our server resources (max open file descriptors).
There are ideas floating around to make that limit higher or disable it for organizations with a large-enough scale (who are, therefore, paying more for our services). This makes sense because we’d know we can “trust” these apps not to try to exhaust our server resources.
What value for the idle timeout were you thinking of configuring?
120 would work for us, could this be higher on larger vm’s for example?
Is there any update on this?