ClientSide ObjectValue.Changed event does not fire when the server sets the Value's parent to nil

[dogwarrior24 (dog)]

Reproduction Steps
Bug happens on all systems. PC, Mobile, and Console.

ObjectValue_Bug.rbxl (37.7 KB)

This game has an ObjectValue in ReplicatedStorage with its Value set to the Part in workspace.
There is a LocalScript in StarterPlayer that listens to the Changed event of the ObjectValue, and prints when the event fires.

To reproduce, simply play solo, switch to server view, and delete the part. Observe that no print occurs despite the client listening to the changed event. If you switch to client view and select the ObjectValue, you will see it’s value is nil.

Expected Behavior
I expect the changed event to fire when the value of an ObjectValue changes, regardless of what caused it to change or what it changed to.

Actual Behavior
When the server sets the parent of an ObjectValues Value to nil, all clients have the ObjectValues Value set to nil, but the ObjectValues Changed event does not fire. Subsequently setting ObjectValue.Value to nil on the server also does not fire the changed event, likely because the client already has the value set to nil.

ObjectValue:GetPropertyChangedSignal(“Value”) also does not fire.

This bug wasted 2+ hours of my time tracking down and creating a workaround for.

Issue Area: Engine
Issue Type: Other
Impact: Moderate
Frequency: Constantly
Date First Experienced: 2022-04-06 00:04:00 (-07:00)

[LordRugdumph]

Currently when objects go away it does not generate active notifications for property changes. For example, if you have a weld whose Part0 was the delete part, the Weld also would not generate a change event.

[dogwarrior24 (dog)]

Are there any plans to change this? This is an unexpected and problematic behavior pattern.

[LordRugdumph]

I am not aware of any plans currently to change it, though I sympathize with the additional complexity this creates for authoring scripts.

[grar21]

Hello, aspiring developer here. I just ran into this issue after finally diagnosing that the client was not recieving a signal for ObjectValues.Value being set to nil. So, according the the wiki the Changed event is fired anytime whenever " the ObjectValue.Value is changed". This means that if the ObjectValue.Value is changed to nil, it should be fired and should be regarded as a legitimate bug? When developing these types of issues are always bound to happen, so you have to figure out a solution. Right now, a temporary solution without having to rework a framework I was making that was based around .Changed events, is to set that ObjectValues Value to a “FakePart” if you’ll call it as a way to get the client to detect a “nil” value.

[dogwarrior24 (dog)]

For anyone else coming here with the same problem, I have found a pretty convenient workaround.

ObjectValue.Value is set to nil on the client when the server removes the object because the ObjectValue’s reference to the object is not a strong one, meaning it does not prevent the object from being garbage collected.

Unlike ObjectValue’s, variable references to objects in-code do prevent objects from being garbage collected. This means a fairly simple fix is to create a reference to the ObjectValue’s current value in-code, and update the variable to match the value of the ObjectValue any time it changes.

This will prevent ObjectValue.Value from becoming nil when the object is removed on the server. That way, the value on the client will always match the value on the server, and the Changed event will actually fire when the server officially sets ObjectValue.Value to nil.

Here’s simple example code that would prevent the bug:

local CurrentValue = ObjectValue.Value
ObjectValue.Changed:Connect(function()
	CurrentValue = ObjectValue.Value
end)

I still think this bug should be fixed. When an object gets garbage collected any corresponding ObjectValues should have their Changed events fired.