MessagingService SubscribeAsync can infinitely yield a script with no error

(Bug speculation, mostly unrelated)

Since yesterday, players in my game World of Magic have been having issues with data loading and other strange issues. When they join, there’s a chance their inventory won’t load at all, and sometimes opening chests doesn’t work. I went in-game to check for server errors and found this:

(Keep in mind, I have not updated my game World of Magic in 2 months, leading me to believe that these issues are a result of yesterday’s Roblox update)

Rejoining a few times fixes their inventory and loads it properly, and there are no related errors to this, or any DataStore warnings. Also this morning, testers started reporting that sometimes they were getting stuck on the titlescreen, and when I investigated this, its because .OnServerInvoke was not firing properly:

(Client)


(Server)
In-game consoles

The script with the .OnServerInvoke is not disabled, and this issue happens entirely randomly. Rejoining can sometimes cause you to load fine, with the server printing “Test1” and “Test2” like normal. When it doesn’t work, the script doesn’t seem to load at all and doesn’t print Test1 or Test2, like shown in the console above.

EDIT: I seem to have found the issue. The following code is a part of the same server script that handles .OnServerEvent for the screenshot above

In servers where loading gets stuck, only “a” prints in the server console

When I changed the pcall above to a coroutine instead, this issue seemingly no longer occurs, so apparently MessagingService SubscribeAsync can now infinitely yield scripts? Me and my testers rejoined the game about 40 times in total and no longer got stuck loading anymore after this fix was applied.

The change should either be reverted or throw some kind of error assuming this is actually the cause of all these issues.

18 Likes

Vesteria is having a similar issue where some players’ character slots are “broken” due to certain servers where their slots are currently located not letting them load in for an unknown reason. When the game fails to load due to this, the player is sent back to the main menu and encounter the same issue when trying again. Based on the reports we received from players, this seems to be an issue across most or all of Vesteria’s maps as well.

2 Likes

Thank you for the report - we’re investigating this issue.

10 Likes

We’ve been having similar issues in Vesteria. Some servers are simply failing to finish loading. In a server I visited yesterday, it seemed that our “boosters” feature was getting stuck loading on the client – which would mean the boosters feature was getting stuck loading on the server. Low and behold, the boosters feature on the server calls MessagingService:SubscribeAsync() during its init process.

Edit: The boosters feature has never gotten stuck in the past, and no changes have been made to it for months.

4 Likes

Similar issue on Steel Titans, some of the lobby servers are broken due to messaging-service failure, which heavily affects our player count, I hope it’s fixed soon

1 Like

Exactly the same issues here servers hub - Roblox

I believe this issue is also affecting my game Starscape. But I already had my SubscribeAsync calls wrapped in coroutines, and the issue appeared to be occurring for PublishAsync calls. Thankfully I have been able to temporarily disable the MessagingService uses because it is not vital to gameplay. Had a brief discussion about it in this thread.

2 Likes

Also happening in one of my games, seems to be happening about 2 out of every 3 times it is called.

2 Likes

My game has a debug panel where I can identify memory leaks. I checked a few servers and none of them have infinitely yielded.

The first two servers are a few hours old, and the third is 12 hours old.
image
image
image

I certainly get lots of errors when connecting, but I haven’t had infinite yielding.

This is the method I use for spawning threads:


I would also like to state that yielding methods like this should never automatically retry internally while yielding. Same goes for DataStore methods. There are cases where the player leaves and the connection is no longer needed, but the retry loop could just keep going internally. If retry behaviors are added, they need to be disconnect-able. Ideally there would be a subscribe method with a callback argument for when it’s ready; A method like this wouldn’t need to yield or error, and could be disconnected at any time in a predictable way. Would be super nice if this applied to DataStore methods as well.

If a new API is added, I’d also prefer it only accepted strings. If developers need to send a table, it’s super easy to just encode it to a string ourselves with HttpService:JSONEncode(); Just provide some actual working examples on the wiki. The current API also receives a mystical table with a .Data field that decodes from JSON, which isn’t even documented and is just redundant and confusing for everyone. We also need binary string support. string.pack was added, but we still can’t use it with MessagingService/DataStores without problems.

Send a string, receive a string, that’s all we need.

4 Likes

Hey y’all - we found the root cause and the issue should now be resolved. Please let us know if you are still seeing issues. We’re reviewing this incident internally to make sure that we can act on problems like this sooner.

15 Likes

I was having the same issues on one of my old games that I don’t work on anymore
It’s ok now though
Also hope arcane oddessy is going well : D

1 Like

We made the critical mistake of not having our subscriptions wrapped in anything for our valentines update and severe pain ensued as I tried to figure out why the main server script broke in some servers

they’re all wrapped up and safe now but glad to hear this is resolved

It’s really confusing and unclear how developers are supposed to handle errors and retry when using APIs like this. We really need methods with “I’m ready” callbacks that are non-yielding and disconnectable. This way we don’t need to wrap and retry in hacky ways, or have edge cases when the method is done yielding but the result is no longer needed, or have hanging references while the yield is going but the player left, for example. The server could retry internally in an optimal way without developers needing to worry about edge cases or unneeded retrying.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.