Replication pauses when tweening BodyScale

I’m trying to make an ability that allows players to grow large then shrink back to their normal size. I’m a fan of smooth effects so I’m using TweenService to accomplish this using R15’s BodyDepthScale, BodyHeightScale, etc. However, for some reason, while the tween is playing, the CFrame of the player that’s growing is no longer replicated to other clients even though the server sees correct outcome. What’s going on here?

https://streamable.com/40chk

This snippet of code is run on the server when the player activates the ability

 --the player's original zoom distance
local oZoom = data.oZoom

--checks if player is already a giant
local giantInfo = RDS:GetState(sPlayer.Name, "Giganto")
local dur = varTable.growTime
local scale = varTable.scale

--the scale NumberValues
local depth = sHum.BodyDepthScale
local height = sHum.BodyHeightScale
local width = sHum.BodyWidthScale
local head = sHum.HeadScale

--if the player is already a giant...
if giantInfo then
    --original depth, height, etc
	local oDepth = giantInfo.oDepth
	local oHeight = giantInfo.oHeight
	local oWidth = giantInfo.oWidth
	local oHead = giantInfo.oHead
	
    --tween goals
	local dGoal = {Value = oDepth, Time = dur, Style = "Cubic"}
	local hGoal = {Value = oHeight, Time = dur, Style = "Cubic"}
	local wGoal = {Value = oWidth, Time = dur, Style = "Cubic"}
	local headGoal = {Value = oHead, Time = dur, Style = "Cubic"}
	
    --takes away their "giant" state
	RDS:SetState(sPlayer.Name, "Giganto", nil)
	
    --use TweenService to change the values back to normal
	Util:TweenParse(depth, dGoal)
	Util:TweenParse(height, hGoal)
	Util:TweenParse(width, wGoal)
	Util:TweenParse(head, headGoal)
	
else -- if the player is not a giant...

	--save the original values
	local stateInfo = {oDepth = depth.Value, oHeight = height.Value, oWidth = width.Value, oHead = head.Value, oZoom = oZoom}
    --tween goal
	local goal = {Value = "*"..scale, Time = dur, Style = "Cubic"}
	
    --sets them to be a giant
	RDS:SetState(sPlayer.Name, "Giganto", stateInfo)
	
    --tween service to increase the scale values
	Util:TweenParse(depth, goal)
	Util:TweenParse(height, goal)
	Util:TweenParse(width, goal)
	Util:TweenParse(head, goal)
	
end

Why not just use TweenService?

Util:TweenParse is using TweenService, it just allows me to set the tween information faster

Try using TweenService, it should improve response time.

The problem persists using only TweenService

I think you should try to use TweenService normally, if that doesn’t work you should mess around with anchoring the player.

As I said in the above post, using TweenService “the normal way” still exhibits the same problem. I would like to be able to solve this without restricting the player’s movement, so I don’t want to anchor them

You should have a look at TheGamer101’s open source avatar scaling function maybe that’ll help you out.

After looking at the clip some more, I noticed that scaling would replicate, but movement would not. After scaling is complete, movement is then replicated. Conclusion: you are overloading replication.

Try doing scaling from server side to see what happens.

Scaling is already being done from server side

My bad, I assumed you were doing it from client. My conclusion is incorrect in that case lol.
Maybe try using client?

Doing from the client does fix the effect for the clients but it breaks it for the server while the tween is playing. Due to the way hitboxes and antiexploit work in my game, this is undesirable.

After you tell all the clients to tween bodyscale why not set the bodyscale on the server to the goal value after a second or something?

For some reason, accessories glitch out like this: RobloxStudioBeta_AoS7aDJXK4

Use remotes to have it replicate to all clients, while still handling it on the client.
Keep in mind tweening is causing the issue. Jumping to a value for the scale will not cause problems.

Doing that resulted in the image in my earlier post. I know tweening is the problem, but why? Especially since it seemed to be fixed back in 2017

You have a bit of an odd situation.
I would file this under Engine bugs.