Skip to main content
Akshay Khurana
Akshay Khurana
New Participant
September 19, 2026
Question

Library component updates stuck in update loop with “Preview unavailable” and incorrect instance counts

We are experiencing an issue with published components from our Tria Design System library in a consuming Figma file (Tria Mobile App (Current)).

Certain library updates cannot be successfully applied. When we accept the update, Figma appears to process it, but the same update immediately reappears. In Review updates, both the current and updated previews show “Preview unavailable.”

There are currently three affected components:

  • Utility Support — simple icon component. This issue has persisted for approximately one week. Review Updates reports 25 instances.
  • Info — simple icon component. This issue has also persisted for approximately one week and reports 2 instances.
  • Text Field Single Line — began exhibiting the same behavior today, immediately after I rebuilt several component properties and published a relatively large update. It reports 2 instances.

Utility Support investigation

This component is particularly easy to reproduce/debug because it is extremely simple: it contains only a vector shape and has no variants, component properties, exposed nested properties, or other complex configuration.

I have already tried:

  • Repair Component Connections
  • Rebuild Connected Instances
  • Updating individual instances
  • Update All
  • Republishing the library
  • Locating and manually replacing known instances

None of these resolves the issue.

There also appears to be a discrepancy between Figma’s library-update state and the actual document.

With “Show updates for all pages” disabled, Figma reports “1 of 25 instances” of Utility Support on the current page. However, searching that same page for Utility Support finds only 2 actual instances. Those two instances can be selected and navigated to normally.

Across the document, Figma’s search also does not appear to account for the 25 instances that Review Updates claims require updating.

As a test, I recreated Utility Support as a completely new component with a new component identity and published it. The newly created component works correctly and does not enter the update loop.

This makes me suspect there may be stale/orphaned instance references or component metadata associated with the original published component.

Text Field Single Line

The text-field issue may have a different trigger.

Unlike the two icons, which have been affected for approximately a week, Text Field Single Line only started failing immediately after a substantial component-property restructuring and library publication today.

It now exhibits the same consumer-side symptoms:

  • Preview unavailable
  • Update appears to apply
  • Update immediately returns
  • Component remains listed under library updates

I have not recreated or replaced this component because it is a heavily used design-system component and I would like to preserve the current state for investigation.

Expected behavior

After accepting a published library update, the affected instances should update and the update should disappear from the pending library updates.

Actual behavior

The update appears to process but immediately returns. Review Updates cannot generate previews for the affected instances, and in at least the Utility Support case, the number of instances reported by Review Updates does not correspond to the instances discoverable through Figma’s document search.

Could you please investigate the underlying component IDs / instance references / library update metadata for these affected components? In particular, it would be useful to understand what the 25 Utility Support instance references in Review Updates correspond to, since they do not appear to be discoverable in the document.

I can provide edit/view links to both the Tria Design System library file and the Tria Mobile App (Current) consuming file, as well as screenshots/video demonstrating the issue.

Environment
Figma Desktop for macOS
Issue reproduced in: Tria Mobile App (Current)
Library: Tria Design System
Date observed: September 20, 2026


Link:
 


Update:
 

I performed a full document-graph audit using Figma Agent, hydrating all 13 pages and 10,000+ instance nodes.

The Agent successfully identified the exact 25-instance cohort reported by Review Updates as:

Home Topbar → Buttons Icon → Support

All 25 instances successfully resolve to Support component ID 1832:254367, key c9631ff30b5d53dea47c57df0c0e9314fd338870.

The audit found no unresolved component references, stale component-property mappings, missing nodes, invalid instance swaps, missing variables/styles, structural mismatches, or broken override targets.

All instances use the current valid Buttons Icon property Icon#188:32, and the Support swap resolves correctly.

Critically, other Support instances outside the 25-instance cohort have identical observable state but are not included in the pending update.

As an additional diagnostic, I completely removed the relevant Support dependency from Home Topbar and published the library. Review Updates nevertheless continued to report the same 25-instance pending update. I subsequently restored it because it is part of the intended design.

The Figma Agent’s conclusion is that there is no document-model-visible difference explaining the pending update. The remaining suspected state is library revision/update bookkeeping that is not exposed through the document model.

 

    10 replies

    Akshay Khurana
    Akshay KhuranaAuthor
    New Participant
    September 19, 2026

    Update: 
     

    I performed a full document-graph audit using Figma Agent, hydrating all 13 pages and 10,000+ instance nodes.

    The Agent successfully identified the exact 25-instance cohort reported by Review Updates as:

    Home Topbar → Buttons Icon → Support

    All 25 instances successfully resolve to Support component ID 1832:254367, key c9631ff30b5d53dea47c57df0c0e9314fd338870.

    The audit found no unresolved component references, stale component-property mappings, missing nodes, invalid instance swaps, missing variables/styles, structural mismatches, or broken override targets.

    All instances use the current valid Buttons Icon property Icon#188:32, and the Support swap resolves correctly.

    Critically, other Support instances outside the 25-instance cohort have identical observable state but are not included in the pending update.

    As an additional diagnostic, I completely removed the relevant Support dependency from Home Topbar and published the library. Review Updates nevertheless continued to report the same 25-instance pending update. I subsequently restored it because it is part of the intended design.

    The Figma Agent’s conclusion is that there is no document-model-visible difference explaining the pending update. The remaining suspected state is library revision/update bookkeeping that is not exposed through the document model.

     

    adamsmasher
    Figmate
    adamsmasher
    Figmate
    September 19, 2026

    Hi ​@Akshay Khurana, thanks for documenting this so thoroughly. 

     

    Since you’ve put a lot of time into troubleshooting this and ruled out a lot of causes, I’d like to take this to our Technical Quality team. Before I do that, though, I have a few more questions to help give as much information as possible with the ticket:

    • If you enable the Tria Design System library in a brand-new blank file and insert the original Utility Support component, does that new instance immediately show an available update or “Preview unavailable”?
    • If you insert a fresh instance of the original Utility Support component into Tria Mobile App (Current), does the new instance also enter the update loop?
    • Are you seeing this in any other files that consume the library, or only Tria Mobile App (Current)
    • Can another editor reproduce the behavior? If possible, does it also occur in the browser?

     

    Once we’ve narrowed this down, I’ll make a ticket for you with the team for a deeper investigation. Thanks!

    Carlos_Villalba
    Carlos_Villalba
    New Member
    September 29, 2026

    Following this closely — I'm seeing the exact same behavior on a different library/file pair, also for about a week now:

    • Library source: 04 - Design System NR
    • Consuming file: 03 - E Web NR

    Answering the questions above:

    1. Haven't tested "Preview unavailable" specifically, but a brand-new blank file with the library added still shows the stale (pre-update) state for the component.
    2. Yes — a fresh instance created directly in the consuming file, with zero overrides, still resolves to the old component state (old size, missing variable binding).
    3. Only tested with one consuming file plus a full duplicate of it — both affected identically.
    4. Haven't tested browser vs desktop or a second editor yet, can do if useful.

    I also tried creating a brand-new component + variable from scratch (never published before) — same result, never showed up as an update in the consuming file. And republishing with "no changes" reported on the source side even though the consuming file is clearly stale. Would be great to get folded into the same investigation if possible.

    djv
    Figmate
    djv
    Community Support
    September 30, 2026

    Hey @Carlos_Villalba, thanks for chiming in here and sharing these details!

     

    The fact that a fresh instance remains stale in both the original file and its duplicate, and that a newly created component and variable never appeared as updates, makes this look broader than the original component metadata.

     

    I’d like to add your files to our investigation. Are you able to share links to the source library and affected consuming file with us? Can view access to support-share@figma.com should be enough to take a closer look. If possible, confirming whether another editor sees the same behavior would also help us rule out anything account-specific. Let us know, and we’ll pass this onto the team. 

    Carlos_Villalba
    Carlos_Villalba
    New Member
    October 5, 2026

    Thanks! Both files are now shared with support-share@figma.com with view access:

    Regarding another editor: a teammate tested it from their own account. They inserted a fresh Button instance from the library and saw the same stale state — the component loads, but the height variable (--btn-md-height) is not bound, so it still renders at the old height. So this doesn't appear to be account-specific.

    One more data point: I just deleted 5 stray components from the library and published. In the library file itself, the Assets panel immediately stopped showing them, so the publish clearly went through. However, the consuming file still shows no available updates at all. So publishing works, but the update isn't being delivered to consuming files.

    Happy to run any other test on my side if it helps narrow it down.

      Akshay Khurana
      Akshay KhuranaAuthor
      New Participant
      October 2, 2026

      I think I accidentally posted twice. This should ideally be merged with this thread:
       

       

      adamsmasher
      Figmate
      adamsmasher
      Figmate
      October 3, 2026

      Hey, ​@Akshay Khurana! Thanks for flagging the other thread - very helpful! Because of the way our forum software is, I can’t move this thread because of the reply from another member. I’ll note on your other thread that this duplicate thread exists, though, that way we all stay on the same page. Thanks again!

      seohyeonpark
      seohyeonpark
      New Member
      October 4, 2026

      Hi @Carlos_Villalba,

      Try:

      1. Restarting the device: Clear temporary including but not limited to glitches, cache, RAM and etc..

      2. Check for Invalid Properties: Remove them.

      3. Re-pair MCP: Re-sync the library.

      4. Publish in Smaller Batches: Export all files in Library to your local. (Optional: if you have external hard drive or cloud access) Save everything there (Backup), then finally clear Figma’s sever-side Library data. Don’t rebuild from the scratch. Use the backup by curating carefully. You have full control. 
      5. Create Automated Workflow: Reduce file size while preserving all data and tag them by colour.


      seohyeon

      Terms & ConditionsAccessibility statement