We keep getting annoying redundant change to the order of PrefabInstance.m_Modifications[]

We have a persistent issue where a prefab file will show up as changed in git, even though nominally we haven’t touched it.

If I look at the diffs it is always the same block of modifications to a nested prefab instance.

It is hard to see in one screenshot, but the block of properties will get deleted from the top of the m_Modifications list:

and reappear at the bottom:

The contents of the blocks are identical.

Our world is broken up into large tiles and there is an Environment prefab for each tile. These changes are showing up in the tile prefabs, and It always seems to happen to nested instances of the same prefab (Waterfall3).

I went hunting and found some very old threads that sound similar but they were all several Unity versions ago and claim to have fixed it. (We are on Unity 2022.3.20 LTS, well after then that fix should have landed)

And the associated issue:

What is the correct order for those modifications to be saved in? I want to try and work out if this is an error that snuck in to source control, and the correct course of action is to just commit these changes and move on, or if this is something persistent in our project that keeps setting them to the “wrong” order, which will need more investigation on our end.

Hello,

We are sorting m_Modifications by target and for the same target we are sorting them by propertyPath. In this case the problem is caused by how we represent target internally - we optimize the representation, but it is dependent on the loading order which will cause targets with different guids to not be stable in different Editor sessions.

Can you please file a bug or reply with the exact steps you used to obtain the file which has targets with different guids?

Thank you!

I’m not sure yet what triggers it and I don’t feel that I can recreate the problem reliably enough to submit a bug report. Also it only seems to happen to this one set of prefabs in a massive project, I don’t have confidence I’d be able to demonstrate it in a stripped down test project that I can submit in a bug report.

Looking at the git history of some of these files, someone will add the a new nested prefab instance. It’ll get checked in to git, then some time later there will be another change, usually from someone who shouldn’t be touching those prefabs, but hasn’t noticed that the have snuck into a big commit and the order will change.

I suspect we’d see more of it in the git history, but the team has gotten pretty good at spotting these changes and discarding them.

I don’t know if it significant but browsing through the git history of the examples I currently have sitting in my modified files the change always seems to be to the first or last object in the m_Modifcations list. That is, the first object will jump to the last place in the list or the last place object in the list will jump to the top of the list. I have yet to see something jumping from or to the middle.

Is there any way to know by looking at the target fileIDs and guids that are serialized in the YAML what the sorting order should be? how are you generating and comparing the optimized internal representation of target that talk about?

If I knew which commits were sorting the modifications correctly and which ones were breaking it that might give me some clues as the whether there is a common cause in the workflow of the people checking in the mis-sorted version.

No, the sorting target sorting order is based on the order in which the assets are loaded and can’t be predicted. The interesting part is that you have multiple targets in m_Modifications which is not correct and most likely resulted from using replace Prefab feature. Can you try to use Remove unused overrides feature to clear the invalid targets? By doing this all overrides should have the same target guid and the guids sorting order should not matter.