Updates to Teleport sessions

Hi Creators,

To prevent exploiting cases, we are pausing Teleport sessions when the Roblox app menu is open, and automatically resuming them once the menu is closed. There are no actions needed from you or your users.

Currently, Teleport can be requested at any time, and if a user is in the middle of some action, it will be interrupted by a Teleport. For example, if a user is using an experience menu to report inappropriate content or behavior, a requested Teleport will interrupt that activity, effectively preventing the report from filing and all the user-filled content will be lost.

To make the user experience more smooth and prevent undesired interruptions, we are making the following changes:

  • Teleport requests started after the experience menu is opened will now be put on hold while the menu is kept open and will be resumed once the menu is closed.

  • The user will be informed about the paused Teleport, so they can close the menu if they want to be teleported without further delays (e.g. to join the next level with their groups of friends).

  • A teleport call made while the menu is open will only wait paused for 5 minutes, it will be cancelled after that if the menu continues to remain open.

Please share your feedback in the comments below.

Thank you.

[Update] October 13, 2022


This topic was automatically opened after 10 minutes.

This seems like a nuisance of a behaviour for the majority of players, whilst only being marginally beneficial for a small minority of players. For games with matchmaking, it’s not uncommon for users on desktop to tab out whilst waiting, and those users are going to be stuck & delaying the teleport, potentially slowing down the match in the new instance from starting. I think that this behaviour should be reserved purely for the report screen, or there should be different behaviour when it comes to delaying the teleport – potentially cancelling it would be better… Not convinced this is the right solution to the problem.


Will TeleportService:TeleportAsync yield for up to 5 minutes until all paused requests are processed, or will it return without delay due to pausing?


Why not just make games reportable on the website?

Edit: And in fact, they are, so I don’t see the problem


Seems a bit problematic for matchmaking applications that rely on players being teleported somewhat at the same time.


Will this in anyway interfere with games that don’t use teleport menu’s … that want teleportation to be seamless and largely unnoticed ?

1 Like

I have not tested this at all yet, but in theory, it should not. TeleportAsync is an asynchronous function meaning other code will continue to execute without waiting for TeleportAsync to finish and return a result.


Very problematic for matchmaking in BedWars.


Yes, I am asking if it will yield until all paused requests are completed. If that were true, this would be a major change that would seriously impact games with matchmaking.

It seems implied that it would, but it’s such a breaking change and the post says this. Maybe it means that only calls on the client to other teleporting functions will be delayed for up to 5 minutes?


I’m sorry but I don’t see anything wrong with this. If you are in your escape menu, it means you are either changing your settings, or AFK.

If you are changing your settings, you would actually get a window indicating a teleporting is put on hold (as stated in the announcement)

If you are AFK, then what your game is doing doesn’t really matter at some point.

1 Like

I can see this as a good and bad thing depending on case to case. Hopefully this turns out to be a good update

1 Like

I understand some players might not wait 5 minutes inside my game lobby, but please clarify this to me since I am kinda confused about it.

:red_circle: Currently, my game lobby shows a loading screen while they are being teleported and removes all other UI, if it fails it pops everything back. (If it gets canceled and not even triggers with an error of teleportation, the loading will be stuck)

Does this mean that if the player is just in the menu while we requested the player to teleport, this teleport action will be canceled and the player will not be teleported after passing those 5 minutes?

:thinking: If “yes” is the answer, is there any event that would trigger when this cancellation happens? I probably misunderstood the entire post, not sure…


I think this should be more customizable, like after how long it will force teleport them, on what in the menu (player list, report, etc.), and if this applies to their experience.

1 Like

I think a better solution would be to move the important menus (e.g. reporting) outside of the context of a specific game session, so that developers can rely on teleports occuring immediately without having to deal with weird edge cases from players keeping menus open and potentially avoiding teleport altogether.

Like, just keep the report menu open no matter how many teleports happen and when? This seems much more robust. I understand it may be difficult from a technical perspective, but as far as I can tell it’s a much better design decision.

You say the motivation is to prevent exploits, but this kind of behaviour is exactly the sort of thing that could enable different kinds of exploits or bugs in specific games where the developers did not handle and test these situations properly.

That’s my two cents anyway.


Will there be any new API associated with this new menu behavior?

This would be useful for developers. A couple examples off the top of my head, if the menu is open for 5 minutes, we could prompt a new UI to teleport back to the lobby. Or if the menu is closed, we could play a sound effect so players close the menu. Or for match making, if a player has the menu open for X amount of time, we could choose a different player from the queue.

I’m mostly fine with these sorts of updates, as long as developers are equipped with tools to develop their games around them



‘Async’ in the Roblox API sense means that the function will yield, for instance, HttpService:GetAsync or GlobalDataStore:SetAsync, unlike the meaning of ‘async’ in other languages or in fact conventional meaning of asyncronous.

ETA: I cannot confirm nor deny (and am unwilling to test at this time) if this affects code execution at all, let alone server execution. I presume OP will be willing to answer this and the other questions asked here to clarify.


In this case, then the update being pushed here is quite concerning because any user can now yield server execution of code for up to 5 minutes unexpectedly.


In terms of Bedwars I suggest not letting the party leader queue if someone in the party has their menu open. That would mostly fix it.

1 Like

That wouldn’t solve the issue of someone opening the menu after they have been queued and are actively in the process of being teleported. In theory, someone could teleport into a BedWars round 5 minutes into it now. Although there are ways to solve this, developers shouldn’t have to rework parts of their games because Roblox ignores the need for backward compatibility in updates and changes.