:Destroy from the Client on something that is inside LocalPlayer.Character will not fire .Destroying on the Server

Reproduction Steps

Server doesn’t receive Destroying event from Client.rbxl (37.8 KB)



local Players = game.Players

local function handlePlayerAdded(player: Player)
	player.CharacterAdded:Connect(function(character: Model)
		local localscript = script.LocalScript:Clone()
			print(localscript, "Destroyed")
		localscript.Parent = character


for _, player: Player in ipairs(Players:GetPlayers()) do


	print(script, "Destroyed")

task.delay(5, script.Destroy, script)

print(script, "Destrying in 5 4 3 2 1...")


  16:29:21.553  PlayerAdded  -  Server - Script:4
  16:29:21.592  CharacterAdded  -  Server - Script:6
  16:29:22.170  LocalScript Destrying in 5 4 3 2 1...  -  Client - LocalScript:7
  16:29:27.174  LocalScript  -  Client

Expected Behavior
I expect the server to fire / receive .Destroying when an Instance is destroyed from any context when the Instance’s change is replicated

Actual Behavior
.Destroying doesn’t fire / received when an Instance is destroyed from Client when the instance is under LocalPlayer.Character

I think the problem is for the Server it just moves the Instance to nil instead of actually calling :Destroy on the Instance.

The reason why I’m having this problem is because I am controlling playback of Sounds and making them Stop and Destroyed after a period of time on each Client, this is because Replication can be slowed down and .Stopped .Played or whatever will not replicate in a timely manner and cause the Sound to still play which is bad UX and unwanted behavior.

Now when you fix this make sure .Destroying is fired properly on other Clients as well

Issue Area: Engine
Issue Type: Other
Impact: High
Frequency: Constantly
Date First Experienced: 2022-04-12 00:04:00 (+07:00)
Date Last Experienced: 2022-04-12 00:04:00 (+07:00)


I dont think this is a bug. because you destroying something from the client via local script, it will not replicate to the server.

Same thing goes for stuff like playing a sound locally, the server and other clients will never hear the sound unless replicated or played from a server script.

Remote events may also come in handy

1 Like

@Ethanthegrand14, I don’t think you understand how Roblox works.

The LocalPlayer has complete control over their Character, if they delete something INSIDE LocalPlayer.Character then it is Replicated.

The problem is .Destroying isn’t firing for that but it should because it is being replicated.

I wouldn’t be having this problem in the first place if what you said is true because the Sound is missing on the Server when it’s deleted from the Client

You don’t have to take my word for it, you can use the sample place and observe what happens.

Or read this Client destruction of character objects replicates to server

Oh my bad. I thought it was only physics and animations the client had complete control over. Had no idea it was the same thing for your character

Yeah. This seems like the direct result of the lack of documentation [and making a new policy] for the against-the-FE-grain of having client destructive control of the Character.
Over the years many have posted on the subject and many improvement ideas have been shared as well.
The fact that this has been “swept under the rug” I bet is the reason it was “forgotten” about.

The article on the fixed Destroy() replication (and new Destroying Event) talks about how it is
Server-to-Client, and only mentions in passing the security implications of it going the other direction.

Given this, it appears that the special-case of the local character may have been completely overlooked.

And given this post, it’s not unreasonable at all to assume that this should work Client-to-Server:

Hi @RuizuKun_Dev ,

We believe this issue should be solved with the introduction of Workspace.RejectCharacterDeletions. With this feature enabled, the server will no longer allow replication of deletions from instances inside your own character. Please let us know if you have any further concerns relating to this.

You can read more about the feature here:


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.