Repository navigation
Support cancelling MultiplayerService session joining functions #3655
Description
Activity
- addedtype:featureNew feature, request or improvementNew feature, request or improvementstat:awaiting-triageStatus - Awaiting triage from the Netcode team.Status - Awaiting triage from the Netcode team.stat:reply-neededAwaiting reply from Unity accountAwaiting reply from Unity account
on Sep 8, 2025 Hi, thanks for your submission!
There's a lot complexity in this space as
CreateOrJoinSessionAsynccan start the allocation of cloud resources. Due to this "cancelling" a request can have some different meanings.Cancellation could mean:
- Cancelling the allocation of cloud resources.
- Cancelling the call to start the
NetworkManager.
For oir information, which type of cancellation are you thinking here? Are there other cancellation behaviours you're looking for?
- addedstat:awaiting-responseAwaiting response from author. This label should be added manually.Awaiting response from author. This label should be added manually.and removedstat:reply-neededAwaiting reply from Unity accountAwaiting reply from Unity account
on Sep 10, 2025 I'd like to cancel the network manager start call. While cancelling cloud resource allocation would be nice, I'm more concerned about this from a UX perspective: I don't want to make the user wait to finish connecting if they decide not to connect.
- addedstat:reply-neededAwaiting reply from Unity accountAwaiting reply from Unity accountand removedstat:awaiting-responseAwaiting response from author. This label should be added manually.Awaiting response from author. This label should be added manually.
on Sep 10, 2025 - addedstat:importStatus - Issue is going to be saved internallyStatus - Issue is going to be saved internally
on Sep 10, 2025 To add to this, we're also having some issues with cancelling as the players have a lot of freedom in our game related to how sessions are created. To give some context, players can freely enter "portals" which establish a session in DA, while its being established (which can take some time) they can hop into another level portal which starts creating a new session - this is where I need to cancel the old call. If the session API were to support cancelling (e.g.,
CreateOrJoinSessionAsyncin this case), I'd expect all underlying UGS calls to be cancelled/reverted so they're not in a partial state where for example a Lobby is created and a Relay is not.Though I understand that this can be quite complex, seeing as none of UGS support cancellation, however I think this is quite a big oversight when dealing with
asynccalls.The team that is maintaining the SDK are working on the full comprehensive cancellation path, however it's a complex space with a lot of moving parts. Cancellation was definitely overlooked while building the initial implementation.
It's very useful for them to know which parts to prioritize as they build out cancellation. Obviously the end state is that everything, including the cloud resources, is cancelled cleanly and intuitively. Knowing whether the cloud resources or the local
NetworkManagerexperience is more immediately painful helps a lot in deciding what needs to be implemented first.Reacted by Edvinas Danevičius and trev3d- addedstat:awaiting-responseAwaiting response from author. This label should be added manually.Awaiting response from author. This label should be added manually.and removedstat:reply-neededAwaiting reply from Unity accountAwaiting reply from Unity account
on Sep 11, 2025 Personally I'm experiencing most issues with "zombie players" staying in lobbies when a connection was cancelled or the player leaves without a clean disconnect. I'm also using
CreateOrJoinSessionAsyncin combination withMatchmakeSessionAsync(trying out various methods to see which one is more stable). In some cases on my end, UGS thinks that a player is in a lobby and producesplayer is already a member of the lobbyerror (don't have the full log at hand right now), which renders some lobbies un-joinable for players in some cases. Given this I'd say priority should be on making sure lobbies are correctly cleaned up on cancel when using session join functions specified in join session docs. Next would be Relay I suppose, however I haven't seen any errors related to that just yet. Perhaps @trev3d has some more ideas, I don't want to hijack the issue 😅Reacted by trev3d- addedstat:reply-neededAwaiting reply from Unity accountAwaiting reply from Unity accountand removedstat:awaiting-responseAwaiting response from author. This label should be added manually.Awaiting response from author. This label should be added manually.
on Sep 11, 2025 In some cases on my end, UGS thinks that a player is in a lobby and produces
player is already a member of the lobbyerror (don't have the full log at hand right now), which renders some lobbies un-joinable for players in some cases.I've encountered this too. If you open a new issue I'll gladly comment on it, but we should stay on-topic (cancellation) for maintainers' sakes.
Reacted by Edvinas Danevičius- addedstat:importedStatus - Issue is tracked internally at UnityStatus - Issue is tracked internally at Unityand removedstat:awaiting-triageStatus - Awaiting triage from the Netcode team.Status - Awaiting triage from the Netcode team.stat:importStatus - Issue is going to be saved internallyStatus - Issue is going to be saved internally
on Sep 15, 2025 - removedstat:reply-neededAwaiting reply from Unity accountAwaiting reply from Unity account
on Sep 22, 2025
Is your feature request related to a problem? Please describe.
It takes several seconds to join a session through MultiplayerService. I'd like to let users cancel a connection attempt during the connection process.
Describe the solution you'd like
I'd like to pass cancellation tokens to functions like
MultiplayerService.Instance.CreateOrJoinSessionAsync.Describe alternatives you've considered
I've tried preventing the NetworkManager from connecting to a session if my own connection function wrapping
MultiplayerService.Instance.CreateOrJoinSessionAsyncis cancelled, but I cannot find a clean way to do this. I have also considered modifying theUnity.Services.Multiplayerpackage myself, but I would rather not do this.