I am very aware of pcall(), but it did not work for me in my case.
Basically, in my game, we have a nuke effect that explodes and uses TweenService to simulate a mushroom cloud, as seen here. It goes away after some time, and everything is fine and dandy.
However, increasingly, I see instances where it never goes away, as seen below:
Obviously this is a big problem for gameplay since it effectively blinds players in a lot of game modes.
This is the below code:
function disaster.nuke(plr:Player,bypass:BoolValue)
	if not bypass then
		if rs.gameInfo:GetAttribute("disasterInProgress") == true then return end
	end
	rs.clientRemotes.guiAnnouncement:FireAllClients(plr.DisplayName.." Bought a Nuclear Strike!",Color3.fromRGB(255, 51, 0))
	task.spawn(function()
		disasterCoolDown()
	end)
	local nuke = workspace.disasters:FindFirstChild("nukeSystem",true)
	if nuke then
		local clone = nuke:Clone()
		local ogParent = nuke.Parent
		local info = TweenInfo.new((disasterTime/2), Enum.EasingStyle.Quart)
		local goal = {}
		goal.Size = Vector3.new(100,100,100)
		local goal2 = {}
		goal2.Size = Vector3.new(300,7.468,300)
		nuke.Cloud.Transparency = 0
		nuke.Shockwave.Transparency = 0.1
		for _,p in pairs(players:GetPlayers()) do
			--if p.Team == game:GetService("Teams").Survivors then
			task.spawn(function()
				rs.serverRemotes.gotHit:Fire(p)
			end)
			--end
		end
		local success, response = pcall(function() 
			---tween
			sound.Disasters.Explosion:Play()
			local tweenCloud = ts:Create(nuke.Cloud, info, goal)
			local tweenWave = ts:Create(nuke.Shockwave,info,goal2)
			tweenCloud:Play()
			tweenWave:Play()
		end)
		task.wait(disasterTime)
		nuke:Destroy()
		if ogParent ~= nil then
			clone.Parent = ogParent
		end
	end	
end
Basically, the nuke gets tweened/played, and then it waits some time before deleting the tweened model and replacing it with a clone from before it was tweened.
The model gets successfully tweened, but looks like it gets “stuck” inside the pcall or something, and never gets deleted/replaced.
Since this is a pretty rare bug, I was never able to find an error statement until after it occurred in a random server.
