Weird order on object properties replication? (Instance:SetAttribute and CollectionService's Tags)

[Bitsfps]

Just had a “problem” where using a code similar to the following:

--Server Script
Object:SetAttribute( "ID", Value)
CollectionService:AddTag( Object , "Tag" )

--Local Script
CollectionService:GetInstanceAddedSignal("Tag"):Connect(function(Object) 
    local curID = Object:GetAttribute( "ID" )
end) 

would return a nil value for the Attribute, unless i added a wait() before using GetAttribute.

This (AFAIK) means that the SetAttribute which is being fired Before on the Server, is not yet replicated when the GetInstanceAddedSignal is received by the Client.

so… am i missing something here? is this intended behavior? i’m pretty sure it’s impossible to mess up a simple and straight-foward code section like this one.

[bg9]

This is a race condition where the tag is being added before the attribute, probably not the best way, but you could add wait before checking the attribute or the other way around with a wait before adding the tag

--Server Script
Object:SetAttribute( "ID", Value)
Object:GetAttributeChangedSignal("ID"):Wait()
CollectionService:AddTag( Object , "Tag" )

--Local Script
CollectionService:GetInstanceAddedSignal("Tag"):Connect(function(Object) 
    local curID = Object:GetAttribute( "ID" )
end) 

[Bitsfps]

yeah, my workaround ATM is just the Local Script on a simple loop until it gets the Attribute…

This post is just to know if it’s intended or something could be going wrong, since it’s the same single function setting the value, never seen such weird replication order before on LUAU, my only guess is that both fired under the same tick, but adding tags and attributes replicate in a different order, which would be weird, but not wrong per se.

[bg9]

Yeah you’ll have to stick with that, pretty sure this is normal. It’s been happening for a while on my game and I’ve just used a wait to fix it