Server Authority instance stitching prediction inexplicably causes rollbacks based on attribute names / SetAttribute order

SoildStone · July 24, 2026, 2:24pm

Here is the reproduction file. This is the default new place file, with the only addition being a ModuleScript in ReplicatedStorage called Test which can consistently cause the rollbacks. There isn’t really anything I can provide in terms of visual aid since this is primarily code, but the output should show a rollback & resimulation occurring every second or so indefinitely as soon as you playtest in Studio.
random_rollbacks.rbxl (61.5 KB)

Output will look something like this:

The rollbacks occur regardless of which value Incoming Replication Lag is set as, and regardless of which values are used for Network Simulation delays.
Notably, RunService.Misprediction will not trigger at all, and thus will not reveal what instance is being rolled back or which attributes are causing it. As far as I can tell, there isn’t actually any mismatch between the predicted value and the authoritative value, and the prediction is “hallucinating” one which results in erroneous rollbacks and resimulations. I suspect this may have something to do with instance stitching, as I could not get this to occur with instances that were created outside of the simulation loop.

In the Test ModuleScript, when the tickAttrName variable is "clock", rollbacks will consistently happen. Changing the attribute name from "clock" to "Clock" will cause the rollbacks to cease. I have absolutely no clue why that is.
Additionally, moving the line Folder:SetAttribute("Active", true) from the first SetAttribute call to the last SetAttribute call will cause rollbacks to happen consistently again, regardless of whether the tickAttrName is "clock" or "Clock".

The reproduction file is one way I’ve found of reproducing it, but it seems to occur whenever it feels like it. It’s gotten to the point where I and my collaborators have to halt the development of current projects with Server Authority due to being unable to validate whether something is being properly implemented or not, and the general inability to playtest without a debilitating amount of rollbacks.

Expected behavior

There should not be any consistent recurring rollbacks whatsoever.

SoildStone · July 28, 2026, 2:47pm

For anyone with this problem: the workaround I found is to pre-create the instance with all necessary attributes already defined on the instance, and then calling :Clone() on it during the simulation instead of using Instance.new(). It doesn’t matter what value you give the attributes as long as it’s not nil. You can override these values later on with :SetAttribute() and it won’t roll back, what matters is that the attribute was already defined prior.

It seems that Server Authority has some weird quirks with an attribute going from nil to a value, and vice versa. That looks to be the reason why it was rolling back for seemingly no reason using Instance.new() but works totally fine when cloning an already-existing instance with attributes.

SoildStone · August 7, 2026, 2:32am

Any update on this?

Following up, cloning the instance does not actually fix the issue unlike what I had stated previously; it just reduces the likelihood of it occurring. This makes it very difficult to test a game with Server Authority reliably, since we get rolled back every time a core component uses instance stitching for something (which happens frequently).

The only actual workaround we’ve found is to rename every attribute (and have it be consistent across all scripts) and randomly shuffle the order in which they’re set, repeating this until the issue stops occurring. That’s not a sustainable solution: it takes a huge amount of effort to figure out a combination which doesn’t roll back, and it would need to be redone for every other instance, and again each time a new attribute is introduced.

We need an actual fix (or communication that it’s being looked into, at least) rather than this kind of trial-and-error workaround, especially when this problem essentially stalls proper development of games utilising Server Authority.