When running a test using Team Test clients get added to the server way before they are supposed to. This leads to objects not being replicated to the client as well as PlayerAdded events not firing.
I’m working on a library and created a little light weight module for keeping track of the time called FatherTime. It’s a series of ModuleScripts in ReplicatedFirst and a single LocalScript called bootstrap which starts the system up on the client as close to the start of client as I can get it. There is also a Server script bootstrap in ServerScriptService that requires FatherTime at the start. On the server before the FatherTime module returns it connects to Players.PlayerAdded so it can setup each player as they join. The connected PlayerAdded function prints the players name into the Log for testing purposes. Just after it creates an UnreliableRemoteEvent called Ding and parents it to FatherTime. Ding gets called from the client (also before the module returns) which tells the server the client’s FatherTime is ready and it then uses Ding to estimate Ping times.
Here is the state of the Log and ReplicatedFirst when launching using regular Test mode. Ding exists on the client and the server prints I have joined the game.
However, when using Team Test I instead get a thrown error because Ding does not exist. ReplicatedFirst is supposed to be 100% ready before both the server runs any Scripts and before the client runs any LocalScripts. However, this isn’t happening in Team Test. I had not bothered to use WaitForChild on the Ding event because ReplicatedFirst is supposed to be 100% ready by the time a client runs any LocalScripts. Adding WaitForChild does clear up the error but fails with an Infinite Yield error 5 seconds in because Ding never replicates to the client, ever. PlayerAdded also does not get called when the client joins. Players:GetChildren does show me as connected before PlayerAdded is hooked so I can add a quick loop to handle already connected players. The fact that the Ding event never replicates can’t really be fixed, though.
You can see the results of the Team Test startup here. You can see in the picture that client bootstrap is loading and running long before the server bootstrap is called.
I’ve heard from two other people that Team Test skips their PlayerAdded events and I’ve verified it happens to me as well. Another person reported they had objects not replicating to the first client that connects to the server leading to many Infinite Yield errors. I do not know where these objects were being parented. I’m seeing the same results with the Ding event in ReplicatedFirst. I don’t personally use Team Collab but I started it up to try and see if it broke for me and verified both issues others have talked about.
Expected behavior
Ideally the server would be given a chance to start up and run before the client does.
However, PlayerAdded can be fixed with a GetChildren loop and WaitForChild can handle things taking time to replicate so at the minimum all objects created and parented to ReplicatedFirst, ReplicatedStorage and Workspace need to correctly replicate to the client, even if the client somehow manages to start up before the server.
This started happening recently without any changes to my experience. The live published game works correctly, and Play Solo also works as expected. The issue only occurs when using Team Test in Studio.
In my case, the first client that joins the Team Test server never finishes initializing correctly. Objects that should be available immediately on the client never appear, causing multiple WaitForChild calls to yield indefinitely. For example, ScreenGui instances that are present in StarterGui are never replicated into the first client’s PlayerGui, even though they are replicated correctly in Play Solo and in the published experience.
The second client that joins the same Team Test session initializes normally, which makes this look like an issue affecting only the first client connected to the Team Test server.
I also see behavior consistent with server-side initialization occurring after the first client has already started depending on replicated objects. This results in missing replicated instances and cascading initialization failures.
Since the published game behaves correctly, this appears to be specific to the Team Test environment rather than the experience itself.
The same thing happened to me, I used a PlayerAdded event on the server, and it never runs for the first player. I tried disabling all of my plugins which didn’t seem to do anything, for me, it always happens when team test is used, no matter the game
Howdy! I’m sorry to hear you’re experiencing this issue. Is this something that popped up recently, or is it something you’ve seen in Studio for some time now? If recent, do you have an idea as to when it started happening for you?
The first report I heard of this happening was from 7/16/2026. Someone said PlayerAdded stopped working for them in Team Test. IdentifyFraud talked about it two days later. In both cases it could be worked around with a GetPlayers loop.
Then Mello_hrt mentioned they had Instances not replicating in Team Test. I don’t normally use Team Create so I turned it on for two of my projects and when I got the same issue in one of them I wrote it all up as I posted above.
Looking back further in the chat history I don’t see any more mentions of PlayerAdded or Instance replication errors any farther back.
Thanks for that info, we’re investigating where this might be coming from.
Just wanted to share a slight correction about the behavior of ReplicatedFirst:
ReplicatedFirst is supposed to be 100% ready before both the server runs any Scripts and before the client runs any LocalScripts
This isn’t quite right. The Server will start executing scripts and running startup as soon as it is online., it does not wait for clients to connect before executing. ReplicatedFirst carries the content that will be replicated to connecting Clients before any other container (eg before Workspace or ReplicatedStorage). The instances in ReplicatedFirst will be replicated to the client in no particular order other than replicating parents before children. Scripts placed in ReplicatedFirst that can execute will execute as soon as they replicate over, it does not wait for the entire contents of ReplicatedFirst before starting execution. This is why WaitForChild is important for scripts that expect instances subject to replication, your script might replicate and execute before the target instance has been created.
Oh! That’s very good to know. I see it’s written in the docs. I guess I didn’t read the full thing. I’ll make sure to start using WaitForChild in my stuff there.
