Deferred Events Jumbling Order Of Replication

I’ve noticed a pretty significant issue with deferred events on while testing…

It seems like when I fire a remote event telling the client that their character has been added to the workspace, and nilling parent purposefully on the server afterwards introduces an issue.

Logically, the client should receive the character being parented to the workspace and then get the signal that it’s parent is now nilled. This is the behavior with deferred events off. However, with deferred events on, when the client receives the character printing the parent would be nil.

Repro code below:

Server:

local PLAYERS = game:GetService("Players")
local RE = game.ReplicatedStorage:WaitForChild("RE")

PLAYERS.PlayerAdded:connect(function(player)
    player.CharacterAdded:connect(function(character) 
        
        repeat wait() until character.Parent == workspace --wait until character's parent is workspace
        
        print(character.Parent) -->  would be workspace
        RE:FireClient(player, character) --> tell client that there is new character
        character.Parent = nil --> would be nil
        print(character.Parent) -->  would be nil
    end)
end)

Client:

local RE = game.ReplicatedStorage:WaitForChild("RE")

RE.OnClientEvent:connect(function(character)
    print(character.Parent) --> should be workspace but instead is nil with deferred events on
end)

`Output:
17:55:46.260 Workspace - Server - Script:11

17:55:46.261 nil - Server - Script:14

17:55:46.635 nil - Client - LocalScript:4
`

I’m coding with deferred events on to prepare for the forced update but it seems to me that it’s introducing a lot more inconsistencies than before.

1 Like

This looks like expected behavior to me. Your event fires and is received by the client, however the handler for the event doesn’t run until after the property has changed.

What are you trying to achieve? I may be able to offer an alternative solution for this.

2 Likes