-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
receive_timeout regarding stream/5 & async_request/3 #243
Comments
Thank you for the kind words! I see your point. I guess, the value that is passed to the recv calls should always be the |
@sneako, what you proposed sounds good to me. I thought I understood what needed to happen well enough to implement it myself, but turns out I don't know what I'm doing. Mint seems to be pipelining requests, and the request Would you like me to push a broken PR? Maybe you'll have some insight into what I'm doing wrong. |
I'm not @sneako, but it seems totally reasonable to push it as a Draft PR! |
Intended to timeout a request with a chunked response after the elapsed time has surpassed the given value. See sneako#243.
Thanks for the prompt @zachallaun, I had been intending to make the PR, but had been focusing on other things. |
Intended to timeout a request with a chunked response after the elapsed time has surpassed the given value. See sneako#243.
Intended to timeout a request with a chunked response after the elapsed time has surpassed the given value. See sneako#243.
Closed via #244 |
Thank you, @sneako! ❤️ |
Thanks for the amazing library!
Finch.stream/5
seems to treat thereceive_timeout
option differently between v0.16.0 & main (9609c40), and I believe it stems from 823cc65.On main,
Finch.stream/5
(andFinch.async_request/3
) timeout after thereceive_timeout
threshold has elapsed, even if data are being received. While on v0.16.0, the connection times out after thereceive_timeout
threshold has elapsed since the last chunk of data (rather than from the start of the connection).Maybe I'm wanting to do something that's not intended to be supported, which is to leave the streaming connection open as long as it's still receiving data (the API I'm calling should send pings every 5 seconds). I can work around the problem by setting a very high
receive_timeout
value and then reconnect on timeout, but it would be nice to somehow have thereceive_timeout
behavior of v0.16.0.The text was updated successfully, but these errors were encountered: