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

improve timeout handling #42

Open
1 of 2 tasks
alee opened this issue Jul 24, 2020 · 2 comments
Open
1 of 2 tasks

improve timeout handling #42

alee opened this issue Jul 24, 2020 · 2 comments
Labels

Comments

@alee
Copy link
Member

alee commented Jul 24, 2020

  • add a setInterval when issuing a query that informs the user that things are taking too long, allow them to reset / extend the timeout until it reaches a maximum
  • clear timeout error messages when the query succeeds
@alee alee changed the title make timeout user-extendible improve timeout handling Jul 24, 2020
alee added a commit that referenced this issue Oct 7, 2020
- distinguish between server error responses (40x/50x responses from the
server) and client errors
https://www.intricatecloud.io/2020/03/how-to-handle-api-errors-in-your-web-app-using-axios/
- add spinners and loading state
- still need to set up timeouts with user feedback for #42

resolves #50
@alee
Copy link
Member Author

alee commented Jun 23, 2021

handling timeouts progressively requires that we navigate multiple layers of the technology stack:

  1. haproxy timeouts as they broker the connection between the client browser and the backend API service
  2. FASTAPI uvicorn timeouts: https://www.uvicorn.org/server-behavior/#timeouts
  3. client side timeouts that can be extended up to a limit (defined by the server side)

To this end, what is the upper bound for max time we can handle?

@alee
Copy link
Member Author

alee commented Oct 5, 2021

This is turning out to be a bigger issue to resolve than simply increasing timeouts. We could have a very long server side timeout and a lower client side timeout that can be progressively increased but that can choke the server / API with long running requests.

A more robust solution would require additional funding for development / engineering and would entail designing the application server and skope-api to use an asynchronous task queue like Celery

https://celery-node.js.org/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant