-
Notifications
You must be signed in to change notification settings - Fork 130
Make useSession wait for agent only if an agent was dispatched #1226
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
Conversation
🦋 Changeset detectedLatest commit: d8cc488 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
4c7ac01 to
3935507
Compare
…kit-client I should be able to get rid of this once this is merged: livekit/client-sdk-js#1710
3935507 to
388ac32
Compare
…rom livekit-client" This reverts commit 0a9c2c5.
size-limit report 📦
|
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.
one question.
| : Promise.resolve(), | ||
| ]); | ||
|
|
||
| await waitUntilConnected(signal); |
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.
without knowing enough context on the code, I wonder if we shoul do both waitUntilConnected() and await agent.waitUntilAvailable(signal); in some cases ?
or it should be something like
if (tokenDispatchesAgent && agent) {
await agent.waitUntilAvailable(signal);
} else {
await waitUntilConnected(signal);
}
also, should you guard agent ?
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.
or it should be something like
waitUntilConnected will block until a the underlying room is connected, and agent.waitUntilAvailable will block until the agent has connected. One is dependent on the other, and while I guess technically the agent could never connect until the room connects first, this should always happen in a sequential fashion so I'm not sure that it really matters that much. So I guess I don't have a strong preference given both should behave identically, but maybe lean slightly towards what I have now.
also, should you guard agent ?
No, this isn't required - agent is always set, but its internal state changes as the agent goes through the connection lifecycle.
As an alternative to #1225, instead of calling
agent.waitUntilAvailable(...)on eachsession.start()call, instead only call it if the participant token dispatches an agent.