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:
- Reload Figma
- 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.
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!