"Properties and values of this variant are conflicting" - but they are not

This issue is not fixed and is incredibly painful

Yeah I guess I’d spoken too soon.

When I place a component from the library file, I have to run the “Repair component” command every time, before it becomes a usable component. So that’s pretty annoying.

​@Dan_Millson - can you reload the file where you are inserting the component and see if that prevents the issue with new insertions?

Okay. I can’t reproduce the problematic behaviour any more, so I suppose it’s resolved.

Hello - the way the solution is worded on page 1 is a little confusing: can somebody clarify if we still need to make “a small change” to affected components before we re-publish? 

Because right below the part about the “small change,” it says “a fix has now been released, and republishing the affected components and accepting updates should clear the errors” with no mention of needing to make small changes. 

Really hoping I don’t need to make small changes across dozens of components 😅
 

Hi all,

We just released a new repair tool that should make it lighter weight to clear the error. You can also select multiple instances at once to apply the repair to all of them (or select the entire page).

One small caveat is that the order of values in the value dropdowns for the different properties might not match the backing component set of the instance. The ordering of properties should still be accurate and values of each property will be correct/unchanged.

The error should clear after running the command, and the ordering within the dropdowns will resync on any subsequent accepted library update. Here are the instructions:

1. Reload the file showing the error.
2. Select the instance showing the error (or select multiple instances or the entire page if there are many different instances showing the error).
3. Run the “Repair backing component set” quick action (Command K on MacOS or Control K on Windows, then type in “Repair backing component set”, then select and press enter).

Let us know if this work around works for you.

​@Tony_Van_Groningen - the repair tool and steps above should help with existing instances of this issue. If consumers reload their file (to pick up the most up to date code), then new insertions and updates should also no longer exhibit the issue.

--John

​

I tried this troubleshooting step of opening the quick action and typing in “Repair backing component set” but when I do the search results in nothing useful.
 

​@Hyun Kim - can you make sure that you’ve reloaded the file to pick up the newest code? Thanks!

​@Dan_Millson - The root cause was related to a version skew issue between the web code and our server code. They share a common code library, and the server code was running a newer version of the shared code than the web. When publishing library updates, component set buffers were getting generated with the newer version, which the web code version did not understand. This resulted in the errors that you were seeing. We do have automated testing for these flows, but they did not cover the specific versioning drift between the web and server that exhibited the error.

Complicating matters, the code also persistently stores these processed buffers when we apply updates, so changing the web code to be compatible with the new version does not immediately fix the issue on reload. We are looking into some more automated fixes to existing files seeing these errors in addition to the repair tools and workarounds described above.

We are sincerely sorry for the disruption this caused and will be doing a full retro to identify ways we can prevent this type of issue going forward. Let us know if you are having issues with any of the repair tools from above.