-
Notifications
You must be signed in to change notification settings - Fork 535
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
fix(client-presence): disabled (failing) attendees unit tests #23419
base: main
Are you sure you want to change the base?
Conversation
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.
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (2)
packages/framework/presence/src/test/presenceManager.spec.ts:83
- The word 'seassionId-2' is misspelled. It should be 'sessionId-2'.
presence = prepareConnectedPresence(runtime, "seassionId-2", "client2", clock, logger);
packages/framework/presence/src/systemWorkspace.ts:202
- The newly introduced behavior for handling stale connections using 'staleConnectionTimer' is not covered by tests.
this.staleConnectionTimer.setTimeout(() => {
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.
looking promising
for (const client of this.staleConnectionClients) { | ||
// Mark the client as disconnected and remove from the stale connection set | ||
if (client.getConnectionStatus() === SessionClientStatus.Connected) { | ||
client.setDisconnected(); | ||
this.events.emit("attendeeDisconnected", client); |
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.
- why do we need the connected check? Because we don't remove them from set when they disconnect in the meantime?
- we prefer to update states to consistent point and then announce events in a group. That way anything responding to the first event and looking at state will get the final state. (This preference assumes that nothing interrupts the thread which is true for JavaScript without any yields.)
So, if we remove the status check, then the state set and events can be done in two simple loops.
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.
Yes, the idea was not to double emit 'attendeeDisconnected'. But I changed to remove attendee from set when they are disconnected/their connection is removed. Also updated to announce attendeeDisconnected's in group after they are all set.
presence.events.on("attendeeDisconnected", (attendee) => { | ||
disconnectedAttendees.push(attendee); | ||
if (attendee !== presence.getMyself()) { | ||
remoteDisconnectedAttendees.push(attendee); |
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.
So, we announce ourselves when disconnecting. Do we have a test for that? I don't think we do, but we should. Task for after.
Description
ADO Bug 24395
This PR enables the previously failing tests presence attendee tests as well as the new ones added in this PR: #23351
When the local attendee disconnects, we temporarily lose connectivity status for remote attendees. To fix this we mark all 'Connected' remote attendee connections as stale upon reconnect and update their status to disconnected after 30 seconds of inactivity.
This PR also fixes some spelling mistakes: "seassionId-2" to "sessionId-2"