镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Support cancelling MultiplayerService session joining functions #3655

Description

@trev3d

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.CreateOrJoinSessionAsync is cancelled, but I cannot find a clean way to do this. I have also considered modifying the Unity.Services.Multiplayer package myself, but I would rather not do this.

Activity

  1. added
    type:featureNew feature, request or improvement
    stat:awaiting-triageStatus - Awaiting triage from the Netcode team.
    on Sep 8, 2025
  2. EmandM commented on Sep 10, 2025

    @EmandM
    Member

    Hi, thanks for your submission!

    There's a lot complexity in this space as CreateOrJoinSessionAsync can start the allocation of cloud resources. Due to this "cancelling" a request can have some different meanings.

    Cancellation could mean:

    1. Cancelling the allocation of cloud resources.
    2. 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?

  3. added
    stat:awaiting-responseAwaiting response from author. This label should be added manually.
    and removed on Sep 10, 2025
  4. trev3d commented on Sep 10, 2025

    @trev3d
    Author

    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.

  5. added and removed
    stat:awaiting-responseAwaiting response from author. This label should be added manually.
    on Sep 10, 2025
  6. added
    stat:importStatus - Issue is going to be saved internally
    on Sep 10, 2025
  7. Edvinas01 commented on Sep 11, 2025

    @Edvinas01

    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., CreateOrJoinSessionAsync in 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 async calls.

  8. EmandM commented on Sep 11, 2025

    @EmandM
    Member

    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 NetworkManager experience is more immediately painful helps a lot in deciding what needs to be implemented first.

  9. added
    stat:awaiting-responseAwaiting response from author. This label should be added manually.
    and removed on Sep 11, 2025
  10. Edvinas01 commented on Sep 11, 2025

    @Edvinas01

    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 CreateOrJoinSessionAsync in combination with MatchmakeSessionAsync (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 produces player is already a member of the lobby error (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 😅

  11. added and removed
    stat:awaiting-responseAwaiting response from author. This label should be added manually.
    on Sep 11, 2025
  12. trev3d commented on Sep 11, 2025

    @trev3d
    Author

    In some cases on my end, UGS thinks that a player is in a lobby and produces player is already a member of the lobby error (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.

  13. added
    stat:importedStatus - Issue is tracked internally at Unity
    and removed
    stat:awaiting-triageStatus - Awaiting triage from the Netcode team.
    stat:importStatus - Issue is going to be saved internally
    on Sep 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stat:importedStatus - Issue is tracked internally at Unitytype:featureNew feature, request or improvement

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions