You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when performing a start/stop the "Auto Refresh" functionality is enabled. This simply performs a GET on the following 2 URLs every 1-2 seconds:
/projects/{project-id}/stacks
/projects/{project-id}/volumes
While this usually works well enough, I have a strong suspicion that this is related to some of the quirks that the UI experiences (such as issue #21).
The current scheme also does not cover the case of multiple users editing the same project. For example: let's say users A and B are both logged into the same project. User A adds a stack slightly before user B adds their stack.
User A will only see the stack that they created, and not User B's stack, due to the race condition.
User B, however, will see both stacks since a successful POST leads to soft refresh that will retrieve both created stacks.
Ideally, we should investigate asynchronous technologies (i.e. WebSockets) to handle this behavior.
The text was updated successfully, but these errors were encountered:
gRPC was brought up as a potential technology that could handle this sort of communication. Unfortunately http://www.grpc.io/faq/ states the following:
Can I use it in the browser?
"Not yet. This is an area that's being actively explored and we welcome feedback and contributions. There is node.js support for server side JavaScript."
Currently, when performing a start/stop the "Auto Refresh" functionality is enabled. This simply performs a GET on the following 2 URLs every 1-2 seconds:
While this usually works well enough, I have a strong suspicion that this is related to some of the quirks that the UI experiences (such as issue #21).
The current scheme also does not cover the case of multiple users editing the same project. For example: let's say users A and B are both logged into the same project. User A adds a stack slightly before user B adds their stack.
User A will only see the stack that they created, and not User B's stack, due to the race condition.
User B, however, will see both stacks since a successful POST leads to soft refresh that will retrieve both created stacks.
Ideally, we should investigate asynchronous technologies (i.e. WebSockets) to handle this behavior.
The text was updated successfully, but these errors were encountered: