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

Appreciate you following up ​@Jayla_Rediger and ​@atlanimator! I’m really glad to hear it. 🙏🏻

​@Darren_Beason1, sorry to hear you’re still running into trouble with this. To help me share more detail back with our engineering team, could you try the following once more and let me know if it resolves the issue: Confirm that the affected components have been republished, and then accept updates in the consuming files to apply the fix.

If the issue persists after that, please let me know and I’ll pass the details along to the team.

We’re back to normal, but I have to share, this consumed about 4-6 hours of our time from problem to diagnoses and reconciliation that prevented other work across our team.

Tried the fix and still not working, and since I’m leaning on a slot heavy design system, most components aren’t fully functional and going through each one would cut into time I don’t have.

Didn’t work.

OK, now I gotta it to work.

Hi ​@Becca_Fuller, thanks for flagging this, and sorry you’re running into the issue as well.

I’ve moved your post into this new thread so we can track related reports in one place while we continue monitoring what’s going on.

Why is this marked as solved. Its clearly still NOT RESOLVED.

[Possible solution for files that are not on a branch and do not contain branches]

Hi ​@Shawn0000001 and ​@Paulo_Custodio1,

Following up on Tom’s note, sorry about these issues you are experiencing. We’ve identified another solution for files that are not on a branch and do not contain branches.

If you are on a file that is not a branch and does not contain branches, can you try the following on the instances that are showing the error?

1. Reload the file with the error.
2. Select an instance that is erroring.
3. Run the “Repair component connections” quick action. (Command K on MacOS or Control K on Windows, then type in “Repair component connections”, then select and press enter).

Can you let us know if this workaround helps?

Thanks,
John

Hey everyone — thanks so much for flagging this and for bringing it to our attention.

I understand that slots are not carrying over to other files, and we’re investigating this further with our Engineering team.

I’ll update this thread as soon as I hear back.

Thanks so much for your patience in the meantime.

Re: 

[Possible solution for files that are not on a branch and do not contain branches]

Hi ​@Shawn0000001 and ​@Paulo_Custodio1,

Following up on Tom’s note, sorry about these issues you are experiencing. We’ve identified another solution for files that are not on a branch and do not contain branches.

If you are on a file that is not a branch and does not contain branches, can you try the following on the instances that are showing the error?

1. Reload the file with the error.
2. Select an instance that is erroring.
3. Run the “Repair component connections” quick action. (Command K on MacOS or Control K on Windows, then type in “Repair component connections”, then select and press enter).

Can you let us know if this workaround helps?

Thanks,
John

This is working for me, however, I need to run this individually on each component that has this error. In my case, there are many… Is there any way to fix this globally within a Figma file?

+1 bumping. Having the same issue 

Still not fixed. “Repair component connections” works but it’s temporary and very time-consuming.
QA your releases please you’re not a small startup.

This works, but I have hundreds of components in a complex file and a tight deadline, and the repair for each is slow to process, so hopefully there’s a forthcoming global fix

​@Jeremie Paret - Thanks for trying out the fix and the additional feedback. Apologies again for the issues here. Can you say more about the temporary nature of the fix? One thing to try might be to reload the design file to make sure you have the most up to date code. We don’t currently expect the fix to be temporary in nature.

We are also actively looking into a tool that is lighter weight and can be applied more easily across the file. Thanks!

Thanks to the team for getting a functional fix up. I’m glad I stopped making things worse for myself this week by deciding to stop working in Figma after the issue was reported on Friday. For a while, I thought it was just an issue I caused myself.

Thankfully I had other busy work that I could do while the SaaS was broken.

Maybe if you are pushing such changes to the core of component relations and introduce bugs like this (just hypothetically, in future), it could be good to have a functionality to trigger a callout to warn users that they are making potentially problematic downstream changes due to a known issue. I know I’ve seen a scary banner about “updating figma or lose access” or “downtime notice” before.

I hope that you get the tool for fixing large documents available for those affected.

Can you share anything about what caused this issue under-the-hood?

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.