Skip to content
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

core: a proper timeout for big upload requests #2575

Open
Augustyniak opened this issue Sep 28, 2022 · 0 comments
Open

core: a proper timeout for big upload requests #2575

Augustyniak opened this issue Sep 28, 2022 · 0 comments

Comments

@Augustyniak
Copy link
Contributor

Augustyniak commented Sep 28, 2022

As it stands now it's tricky - if not impossible - to configure Envoy Mobile timeouts so that they follow typical expectations that mobile engineers tend to have from network requests used to perform big upload requests.

This issue is going to reference Lyft timeout policy but in general, presented scenario should apply to most of the mobile apps.

So at Lyft we have a policy where we want to ensure that each request's retry takes at most 15 seconds. We use per_try_idle_timeout to accomplish that - that's great. At the same time we disable stream_idle_timeout (by setting it to 0) as some of our requests have potentially unlimited number of retries - whether it's a good idea or not is a separate story.

The issue that we are seeing is that when we try to upload bigger files - let's say 10MBs - our requests continue to fail with per_try_idle_timeout timeout. Per the definition of that specific timeout that seems to be an expected behavior.

Now, the question is. Is it possible to configure Envoy Mobile so that it

  • ensure that each of requests' retries takes x seconds at most
  • does not timeout a given request if it continues to receive bytes from server or continues to send bytes to the server?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant