- Notifications
You must be signed in to change notification settings - Fork929
feat: Make workspace watching realtime instead of polling#4922
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This was leading to performance issues on the frontend, wherethe page should only be rendered if changes occur. While thiscould be changed on the frontend, it was always the intentionto make this socket ~realtime anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Nice fix! I was thinking that1 * time.Second would become problematic when I saw it last week. 😄
| _ = sendEvent(ctx, codersdk.ServerSentEvent{ | ||
| Type: codersdk.ServerSentEventTypePing, | ||
| }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Is this needed becauseServerSentEventSender() doesn't send the first ping until the timeout has been hit once? Should we "prime" it in there instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I think we want the caller to indicate readiness by sending theping themselves.
If we don't a race can occur where the client's request has been completed butsubscribe hasn't been triggered yet. We could fix this by moving the initialization below the subscribe and making it send a ping, which seems more reasonable.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Seems like this is a bit trickier than I thought... because we use thesendEvent callback in theSubscribe function, we can't initialize after safely. Seems like we'll have to keep it the way it is, but I'll add a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I added a comment and will leave it as-is for now because nothing comes to mind as being cleaner... if you have ideas leave em here and I'll implement!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Hmm, I don't fully understand the race scenario, but I just realized that thehttpapi.Write above (if err) could be problematic since we've already primedrw for server side events inhttpapi.ServerSentEventSender (and started a timer for pings). So it might be a good idea to change things around a bit 👍🏻. If the subscription fails, I believe this handler wouldn't return until the first SSE auto-ping has been sent (because of the defer <-chan above).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Fixed that error case! Goooood catch
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
@mafredri I also think this is why your CPU usage was so high on the workspace page since the UI had to refresh every second. |
…mments to workspace events
This was leading to performance issues on the frontend, where the page should only be rendered if changes occur. While this could be changed on the frontend, it was always the intention to make this socket ~realtime anyways.