Recap of the override bug that occurred on 01/20

Yesterday, many of you were affected by an issue where variant overrides were lost after you accepted a library update. If you’ve encountered this problem and are still looking for a resolution, please try the following steps:

  1. Reload Figma
  2. Run “Fix instance overrides” from the Quick Actions menu (cmd-/).

If the above recovery steps are not working, please reach out via our Support contact form and we’ll help you with more individualized support.

Since this was such a disruptive incident, we wanted to provide some more visibility into what caused the issue and the work our team has been doing to resolve it.

The original bug

Each layer in an instance is identified by a key. Each override is also identified by a key. When an override key matches a layer key , we know to apply that override to that layer. For about 24 hours, variants were published with corrupted layer keys . Yikes! Here’s how that played out:

Suppose you have a normal instance of the variant in a file, with some overrides applied. It has normal layer keys and normal override keys . After accepting an update to a corrupted variant, it now has corrupted layer keys . It actually still has normal override keys , but because the corrupted layer keys no longer match the normal override keys , we don’t know which layers to apply the overrides to. It appears that overrides are lost.

We knew this would be complex to fully remediate. To optimize for unblocking as many people as quickly as possible, we opted to ship incremental fixes as soon as we had them ready, gradually working towards a complete solution.

The first fix

At this point, we shipped a fix that repairs the layer keys of a variant when you accept an update, without requiring you to republish your library. This means that after accepting any other update to your instance, it once again has normal layer keys . If you hadn’t modified your instance at all, it still has its normal override keys , as explained above. The normal layer keys once again match the normal override keys , and your overrides all reappear.

Here’s where it gets complicated. (If it wasn’t complicated enough.)

If you applied new overrides to the variant while it still had corrupted layer keys , we saved those new overrides under matching corrupted override keys. Now if we were to apply another update, the restored normal layer keys would not match the new corrupted override keys . We would be back to square one where again keys would be mismatched, and it would appear that you lost overrides. :face_with_symbols_over_mouth::face_with_symbols_over_mouth::face_with_symbols_over_mouth::face_with_symbols_over_mouth:

The second fix

This is when we shipped the “Fix instance overrides” menu option. This restores normal layer keys and converts corrupted override keys back to normal override keys. Everything is normal; the keys all match again. The overrides you didn’t touch are restored. The new ones you set are preserved. Happy day!

We shipped this tool as quickly as we could, and so far it seems to be working well. Once we run more tests, we plan to run this process automatically on files, so you’ll no longer need to initiate the action yourself.

The third fix, and the fourth fix, and the fifth fix

If you’ve been around the Figma block, you know that there’s quite a lot you can do with components and instances and variants. It’s a complex system! While the fixes we described above handle the vast majority of cases, there are still a couple of perfect storms that can occur with the right timing of various actions like publish, update, override, reload, nest, swap, publish again, override again, restore version, etc… Our team has built more sophisticated tooling to help remediate any edge cases not addressed by the general fix. Please reach out to Figma Support if you continue to see issues with your file and we’ll help you out there.

We know how frustrating this was for those of you that were impacted. It was rough for us too, and we’re continuing to take this issue extremely seriously. Over the coming weeks and months, our team plans to add additional validations and guardrails to ensure something like this doesn’t happen again. Thank you to everyone who reported the bug, sent us test files, tested our fixes, and helped us get to a resolution. We appreciate your support!

18 Likes

So relieved to hear that this was also “rough for you.”

1 Like

Do you fix this bug? Can we publish component library? and when?

Hey @Jonathan_C yup you should be good to go. If the recovery steps above don’t work please reach out to support via the contact form linked above.

Thanks so much for the detailed overview and the fix! Working fine on my end now. :smiley:

2 Likes

Great that you are hands on and act quickly. The takeaway from this though is that you need more testing before launching new updates. In the past few days I have 3 bugs that disrupts my work:

  • The override bug
  • Comments not showing / taking you to the wrong page
  • Updating master component do not update instances in other files

Also showing the new comment bubbles by default has so many usability issues and inconsistencies. This should have been better tested on users before launching.

So please, in the future, have more robust tesing before publishing new features so it do not disrupt our work.

4 Likes

Has the bug ever been fixed? Can we get any update? It’s been almost a month, and I’m still dealing with the consequences of this bug in my project with 30+ files.

Very constructive sarcasm

Having quite a few override errors currently. It’s becoming increasingly irritating as these are large files I am working with so they take a long time to remedy and the above ‘fixes’ aren’t doing the job, unfortunately. Has there been an update here?