We just experienced an issue in World // Zero and Robloxian Highschool where servers would not run scripts on the client we believe?
Shutting down broken servers fixed the issue - Vehicle simulator experienced the same problem and was fixed by shutting down broken servers.
Initially I thought this was a datastore issue and was hunting that down but all of the requests semed to be working fine.
Might want to make this a ROBLOXCRITICAL when a couple more reports come in, but Jailbreak’s experiencing the same issues and the playercount is rapidly dropping…
Games are breaking out into mass errors, saying “Remote event invocation queue exhausted for did you forget to implement OnClientEvent?” and other errors.
Scripts seem to be completely breaking, with Jailbreak for example, doors refuse to open when they’re supposed to, and the game logic just completely shattered.
Like you said:
These issues don’t seem to be a problem in newer servers. Would love if staff looked into this issue promptly.
I’ll update it to critical since this definitely meets the requirements (not that it’ll send out any alerts 
)
Do you call LocalizationService:GetTranslatorForPlayer[Async] in the code that’s being run?
We just had an issue where the game was getting stuck trying to load something - I looked at where it was getting stuck, and it seemed like the only roadblock could be the GetTranslatorForPlayer[Async] calls infinitely yielding. (I attempt GetTranslatorForPlayerAsync first, and call the old GetTranslatorForPlayer as a fallback if that doesn’t work)
(There were no errors for me, the script just stalled after a certain point)
I changed it so the calls would run in a separate thread that wouldn’t stall the rest of the loading process and restarted my servers. Can’t 100% confirm whether that’s the true cause.
That’d be in line with the FFlags flipped two hours ago that seem to be related to localization. (GetTranslatorForPlayerAsyncEnabledLazyLoad and DynamicLocalizationTablesNonBlocking2)
Yes we do! Will look into if this could be doing it for us as well…
If skipping GetTranslatorForPlayer[Async] fixes your problems, please let us know immediately. We don’t see evidence of issues with that API right now, but it’s possible there’s something that we’re not noticing.
Could probably have been some correlation with GetTranslatorForPlayerAsync. Players in my game had problems with the main local script not loading fully, and that script calls GetTranslatorForPlayerAsync somewhere in the middle. Other places in the universe with the same base script but without that call (among other things) worked just fine.
I haven’t looked into if that’s the exact issue but this is what I could tell from the reports.
This has been confirmed to be an issue with GetTranslatorForPlayerAsync being transitioned from a previous implementation to a new implementation in the scenario that newly connecting clients had a flag enabled (GetTranslatorForPlayerAsyncEnabledLazyLoad) expecting the server to have been initialized with the new implementation (DynamicLocalizationTablesNonBlocking2). Currently running servers that had been initialized with the old implementation were not properly setting internal state allowing for forward compatibility with new clients initialized with GetTranslatorForPlayerAsyncEnabledLazyLoad, leading to LocalizationServirce.GetTranslatorForPlayerAsync buffering the async requests until this internal state was set (which old servers would never set). It follows that the issue does not occur on newer servers initialized with DynamicLocalizationTablesNonBlocking2.
This occurred due to an internal testing oversight and we’ll strive to provide better coverage for similar upgrade scenarios in the future.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
