Undo can corrupt graph

V M 3 years ago updated by Crystalius 2 years ago 46 4 duplicates

Some adventures I had today. All in one long day of messing around with Bolt. [I'm a new user].

  1. I Ctrl+Z to undo and most of my Macro disappears. Almost nothing left behind. I click away and back, nothing, I restart Unity.. all back to normal.
  2. Same thing again, Ctrl+Z to Undo. A bunch of nodes disappear.. I undo again.. even more nodes disappear. Mayhem left behind. I click away, back, I redrag and drop the superunit, I delete it and redrag n drop, I reframe the graph, I restart Unity.. nothing. I didn't try to Ctrl Y.. immediately after Ctrl Z. Anyway, unacceptable catastrophic failure.
  3. One of my graph variables disappears. I'm recreating it. It disappears again. I'm recreating it.. it stays this time. Good job you graph variable you..

All in a day of work.

I have Win 10 x64, and Bolt installed without errors, but I do get some yellow warnings after each Unity boot: Ludiq.DictionaryAsset and Ludiq.VariablesAsset failed.

Night night now..

Bolt Version:
Unity Version:
2018.2.15f1 Personal
Scripting Backend:
.NET Version (API Compatibility Level):
Satisfaction mark by V M 3 years ago

Duplicates 4

Tried to reproduce it, but without success. :-\

Pending Review

Hi Kicktherabbit,

I'm so sorry you had an issue that resulted in lost work. I hope you had a recent backup available.

Actually our programmer Andy also experienced this issue once, but didn't isolate it either.

Can you try to run me through what you were doing before undoing?

Did you get any error or warning in the console?

Does redoing (Ctrl+Y) restore the lost elements?

Nope. Sorry ... I was so irritated, that my first action was another few undos, because I thought maybe I did a strange key combination, where I deleted the stuff. And the next impuls was to close and reload, and hoping that its back. ;-)

And, no ... hadn't a copy, but I was able to reconstruct it quite fast, because I hat some older versions and superunits with parts of it. No prob. 

But I realy tried to reproduce it without result. Don't know what was the point, and why it happend. Always difficult, if a problem just apears so infrequently. 

Next time I will analyse it better ;-) ...

Pending Review

Hi V M,

Sorry you're getting this issue. The report was not ignored, it's just that we haven't been able to reproduce it, so we can't attempt a fix. 

Can you create a simple, small project with instructions on how to reproduce the bug from it?

It's possible this happens only on a few people's machines, because of local settings.. If that is true, maybe you can't replicate. But both issues I've encountered and mentioned here are project-breaking bugs, meaning I can't use Bolt at all unfortunately. I'm not sure if helps, but I can send you my tests project where the bugs have happened [in one of the macros, probably one that either looks broken, or empty, but I'm not using Bolt anymore so no idea which one..]. I have no idea how to use github. Do you have a contact email? I can use Wetransfer.
I'm thinking of keeping Bolt for now, and trying Unity again in a few years. Maybe they come to their senses with that dreadful Logo.. And I hope you can afford to test the product more thoroughly meanwhile, and make it more solid and user friendly. I mean more like Unreal BPs. In BPs when you create a variable, the next one you create doesn't return to some default. You can keep creating tons of floats really fast. Populating long lists manually is not fun in Bolt. There are a lot of missing value transfers [float-to-string and such..]. There are no split pins.. so on. There are many quality of life differences that make Unreal BPs much easier to use and faster to set up.
Cannot Reproduce

Hi VM,

Unfortunately if we can't replicate an issue, we can't even begin fixing it. This is why bug reporting always asks for reproduction steps. Test projects are helpful, if the projects are small and lead to a clear reproduction. You can send them via our private message function (right below the search bar).

I'll be closing this topic as it includes 3 separate issues that were reported elsewhere:

  1. Undo bug: See the thread you linked
  2. Variable disappearing: See the FAQ
  3. VariablesAsset warning: See Known Issues (fixed in Unity 2018.2.18)

Thank you for your workflow suggestions. We're addressing all of the variables workflow issues in a big redesign planned for Bolt 2. Creating common variables will be a 1-click operation (see our mockup), on the left sidebar. I did not know about split pins, we'll look into it!

You also dismissed the other one with a Cannot Reproduce. And we're talking about a major bug that can destroy hours, if not days of work, for someone who doesn't backup their stuff very often.

Also, the undo bug is not about variables resetting to Null. But about a variable I'm using simply disappearing and therefore breaking the Macro.

I can't believe you simply dismiss catastrophic failures like these. Just because you cannot reproduce this now it doesn't mean you should close the case and forget about it. These bugs are not imaginary, and they're still there.

Hi VM,

I can assure you we take any bug that incurs data loss very seriously. In fact, they take priority over any other feature development or bug fix. 

However, if we can't reproduce them, we can't fix them. The context you gave me for the bug is vague; it implies a big project and a lot of successive operations, without any error message, example file, screenshot, log, or reproduction steps. I wouldn't even know where to start to get the issue you experienced.

The link for the private message is right under the forum search bar:

Or you can send us a message at support@ludiq.io.

Or you can upload your project publicly, as long as you have all the rights to redistribute its content and remove the Ludiq folder from your zip before uploading.

I will gladly examine this issue as soon as I can get started.

Yes the content I gave you is vague indeed, sorry about that. I don't have Unity installed anymore, just this very small, simple project.
I'm transferring it to you via WeTransfer. You should get another email containing the download link, but here it is again:
I tried to create some modular character, so look inside the 2D platformer character.
There should be only a few macros in this project, and I think one of them is either empty.. or has an entry node.
That's the macro that got corrupted or something, and instead of a bunch of nodes it has either a few or 1 or none.. I don't remember exactly.
Sorry I can't do more. Hope it helps and good luck!

Hi VM, I downloaded the project, thank you. 

However, please remove your upload from WeTransfer, as it includes all the Bolt assets publicly because they were not removed before uploading. This is in fact redistributing Bolt online illegally.

Oh, I'm very sorry. I don't think I can remove those files myself, but you are the only recipient of this transfer, and the files are going to be deleted automatically in 7 days. In the future think of providing a solution for uploads. The mistake I made is very simple to make, I simply sent you the whole project, I don't even know or care what's inside that zip file anymore, because I'm not using Unity atm. If this issue is important to you, think of allowing users to upload stuff somewhere on a server where only you can have access to files. I'm just trying to help anyway, not to do illegal things. : ] Good luck, and thanks for reconsidering the bug!

This sometimes happens, usually in ctrl+z situations. For some ctrl+y (redo hotkey in Unity) has helped to regain what was lost.

Pending Review

Hi Firebomb,

This seems related to this issue: https://support.ludiq.io/communities/5/topics/2444-multiple-undos-can-cause-graphs-to-disappear-until-unity-restart

Usually, the workaround is just to restart Unity.

But before you do, did you get any error in the console? This issue has been plaguing us for a lot of versions and we were never able to reproduce / isolate it, so any additional information would help.

I've been hitting the undo bug a bunch of times since buying Bolt last week. After reading this thread I've tried to extract some information about what might be happening. In this case I was inside a transition with an embedded flow machine and I hit undo once too many times and the graph went empty. Often times the whole graph goes blank, but in this case only the transition did. I think the change it was trying to undo happened in a different transition. After I left or re-entered the transition I got the following errors: https://pastebin.com/6XWyw1rK

Since then I have tried to recreate it again but can't trigger it fully. I am able to recreate the error without any blank graphs by doing the following steps:

  • Select a transition.
  • Rename it.
  • Enter another transition.
  • Move a node.
  • Hit undo twice.
  • Go back out to the state machine.

The two errors will show up but both undos have succesfully occured. I'm not sure if this means that the errors are unrelated to the blank graph issue but perhaps it will give you a clue as to what is happening here.

I have made a simple project with just Bolt in order to reproduce this and I will keep experimenting with it if I manage to hit the issue again in my main project. This bug lost me a fair amount of work and so I feel incentivized to help fix it! Let me know if I can provide any more details.

Bolt Version:
Unity Version:

2018.3.0f2 Personal
.NET Version:


Hi Zoeee,

First of all, so sorry you lost work to this. If it ever happens again, most users so far have reported that the graphs aren't actually lost, but they only fail to render -- restarting Unity seems to fix it.

Thanks for providing reproduction steps for the error you posted ("Invalid decorator"). This one seems like a fairly easy fix and should land in the next version. It might be related, but I doubt it will fix the main issue.

The second error you posted is a harmless warning throw by the Unity GUI when something goes wrong. It's likely just a side effect of the first error.

I'm also really motivated to fix this issue. It's just so elusive that no one has been able to provide reproduction steps yet... I'm tempted to launch a bounty hunt with a gift card or something, haha!

Holy cow! I hope this comes back after the restart because this was my whole day's work.

I think it's related to embedded superunits or ctrl+z itself.

  1. I created a macro asset, set up some inputs and outputs. 
  2. Then I went back to my main graph and dragged in the macro as a superunit.
  3. I ctrl+x'ed a custom event trigger+saved variable unit from the main graph and pasted the units inside the macro superunit.
  4. Then I went back to the main graph and decided that my superunit idea is stupid and I don't need it
  5. I don't recall 100% but I think I deleted the embedded super unit from the main graph first
  6. Then I hit ctrl+z a couple of times and bam, my graph got nuked.
  7. Since my last changes made were inside the superunit (which I deleted from the graph) I guess the system got bamboozled?

I'll try to reproduce in a fresh scene. Last time this happened to me I also worked with an embedded superunit.

P.S. Ctrl+Y didn't help, Unity restart also didn't help so my graph is dead. :( It was pretty quick to restore because I had shared some screenshots though. Nothing much lost in the end thankfully. 

I got it to repeat a couple of times when working with embedded super units but when I copied the scene so I don't lose the progress on my project and tried to reproduce again, the issue was gone completely.

So I guess if you encounter this issue multiple times in a row like I did, copy your scene, open it, delete the original scene, rename the copy to fit the original scenes name and continue work in there.

Unfortunately when it's gone it's gone in my case, although I didn't know to try ctrl-y so probably reversible, I could see that the _json attribute of the asset had been emptied. My strategy now is to always stage changes to git once I've made a successful change to the graph. That way if it disappears I can reset to the latest version I staged.

I tried to recreate the problem using your steps TowerCrow but wasn't successful in a new environment. This seems the same as your attempts to recreate it and my previous attempts to recreate my issue. Feels like the graph must get corrupted somehow before performing these steps in order for the undo system to break because in my testing it simply brings back the deleted super unit via undo and so it can then undo any changes inside the super unit without getting bamboozled.

I wish I had saved broken files from those first catastrophic failures, but ironically I didn't know about this issue at that point and it still hasn't happened again since. One thing I remember seeing when digging through the JSON originally was that the summary had \t\t in it, I just tried it in Unity now and that field allows tabs. That's a minor UX bug, but perhaps something doesn't like tabs in the summary (Unity serializer for example)? I remember working on the naming of my states around the time that it failed.

"restarting Unity seems to fix it"

This works maybe if you don't save anything? I didn't try to Ctrl Y and indeed restarting worked for me once. The second time I lost all, possibly because I hit Ctrl Z twice.. and maybe I also saved the changes? I don't remember exactly, it's been a while. The problem is that when disaster strikes.. people can panic and do the wrong things.. like hitting Ctrl Z 100 times. : ]


I lost a lot of nodes frequently with CTRL + Z.
It was impossible to undo with CTRL + Y.
This occurs in both bolt1 and bolt2.
Unfortunately, the method to reliably reproduce is unknown.

If I back up frequently while using Vault, I can avoid the worst case.
I like Bolt very much. However, due to this bug I can not recommend it to other staff.
Can you disable CTRL + Z if it seems difficult to fix it?

Absolutely agree with lovepug. I think there should at least be a warning that Undo can corrupt your script, in the Settings, and a way to turn off Undo for Bolt, as a safety measure. I know this doesn't look good for Bolt, to admit it's got a massive, catastrophic bug at its very core.. XD But it would be a very useful safety setting.

I actually can't disable Undo support. We're not allowed to publish editor extensions on the asset store if they don't fully support Undo, it's one of the rules for publishers! 

If nothing shows up in the console, is there some kind of way of logging this problem differently? Is simply filming all I do with Bolt the only way and would that even help if it's not reproducible?

I'm back and will make reproducing and fixing this my #1 priority until I actually fix it. Heck, if I can't reproduce it myself, I'll start a community bounty hunt. ;) I understand your pain and frustration everyone. Thank you again for your patience.


Hi everyone, 

We're moving forward more aggressively on this bug hunt and we created a form to try to understand repro conditions. Please give us a hand by filling it here:


Regarding the problem of CTRL + Z, reproducibility is not yet known.
It may not be related, but I will ask about what I am worried about.

Changing the setting of Naming also changes the settings of other projects. Is this normal behavior?

For Example)
I will make a project of Bolt1 and Bolt2.
 1. Bolt1A --> Human Naming (Create New Project)
 2. Bolt1B --> Human Naming (Create New Project)
3. Bolt2A --> Human Naming (Create New Project)
4. Bolt2B --> Human Naming (Create New Project)

Next, change Naming setting of 1 project.
1. Bolt1A --> Programmer Naming (I changed the setting)
Then the settings of other projects will change as well.
2. Bolt1B --> Programmer Naming (I have not changed the setting)
3. Bolt2A --> Programmer Naming (I have not changed the setting)
4. Bolt2B --> Programmer Naming (I have not changed the setting)

Change Naming setting of Bolt2.
4. Bolt2B --> Human Naming (I changed the setting)
Then the settings of other projects will change as well.
1. Bolt1A --> Human Naming (I have not changed the setting)
2. Bolt1B --> Human Naming (I have not changed the setting)
3. Bolt2A --> Human Naming (I have not changed the setting)

A conclusion)
If the variable type is "Integer" it will be judged as "Human Naming" and "Int" will be judged as "Programmer Naming".
In this way, the setting of bolt1 is reflected in other bolt1 and bolt2 projects.
Likewise, the setting of bolt2 is reflected in the project of other bolt1 and bolt2.

If settings other than "Naming" are also shared, is there a possibility that the behavior may become abnormal due to it?
This is an imagination...I am sorry if this is normal condition.

I hope that the Google translation translates well.

Unity2018.3.6f1 + Bolt_1_4_1_NET3.unitypackage
Unity2018.3.6f1 + Bolt_2_0_0a3.unitypackage

Hi Love Pug,

That is normal but also unrelated. Please create new threads for new issues or questions.

Basically, there are two types of configurations in Bolt: project settings and editor prefs. The naming scheme is an editor pref, hence why it is shared across projects, but not across users. You can learn more about the difference in the Configuration page of the manual:


I am ignorant, it is inconvenient for you. I'm sorry.
I hope that the reproducibility of the problem will be confirmed.


Still investigating this bug as a top priority. Unfortunately, the form replies are all over the place -- there seems to be no consistency whatsoever. I'll have to dive in and try a bunch of operations to try to find one that breaks. Sorry for the extreme delays on this issue everyone; it's escaping capture very aptly!

Hello, we're also experiencing this issue.

Any updates?

Working on Fix

The good news it that I believe I stumbled unto the cause of the bug by working on some other fixes for Bolt 2. I say I believe, because it's just a hypothesis at this point, as we're not able to reproduce it consistently, but it would make sense with the symptoms, logically.

The bad news it that if I'm right, it's incredibly hard to fix, and it's only fixable in Bolt 2, because the bug is inherently related to how FullSerializer works.

The gist of it is: FullSerializer tries to magically reuse object instances when deserializing to save on memory. Somehow, that works most of the time; but if it doesn't, and it remaps an object inside the wrong old shell, then a bunch of highly unpredictable things could happen. Hence the impossible to repro conditions and effects.

Odin Serializer, the better serializer we've switched to in Bolt 2, on the other hand, always recreates new objects. Which is much safer! But it means that any external reference we held to the previous objects are now invalid (as they should be). This causes a whole other set of issues with our editor tooling, which relies on these references to display graph elements.

Basically, Bolt1+FS relied on a weird optimizaton/bug that worked most of the time, and all hell broke loose when it didn't.

Fixing Bolt2+OS so that it doesn't rely on it means creating and maintaining some layer of persistence above the serialized object references, which is no simple task.

I'll keep everyone posted as I progress, but these are my conclusions so far!

Pending Review

Hi AiSard,

Thanks for the report, I'll investigate with your repro steps. This seems related to the ever-escaping Undo Bug, but if you have clear reproduction steps it'll help me isolate it.

Hi AiSard, 

Unfortunately I cannot reproduce the issue from your description. It is likely the same hard-to-reproduce Undo bug reported in the other thread. Merging.

Hi Onur,

I'm very sorry you experienced this issue. I merged it with the megathread about it. Since you were able to reproduce it 3 times in one day, would you be able to give me precise steps that caused it? Reproduction has been eluding us for months and it's what keeps us from fixing it.


Hi Lazlo, I'm getting it randomly when ctrl+z. But in my opininon this occurs when you have super nodes in your graph and mostly if they are as macros. Also if you use that nodes in other graphs and change a supernode from one graph other graphs sometimes corrupt or totally lost (doesn't sync properly). I totally leave using supernodes and for a week I don't have any ctrl+z issue. 

I suggest you that keep a history of graphs like in the jetbrains (local history). So we can revert back before the corruption. Or most simply you can add a manual save button. Thats very annoying that graph corrupts or deletes itself and autosave. And you can do nothing. In my situation nothing worked (ctrl z, ctrl y).


Having the exact same issue, I'm working on a very complete character controller. No issue at the beginning, but now that I have a lots of super states (inside super states, inside super states) I have a graph where I have the issue every time I press ctrl Z. 
I'm using 2019.3.0b3 though.
I'll try to make a debug / repro project ! 

Edit : Of course, after upgrading my project to 2019.3.0b4, I don't have the issue anymore. If it's happening again, I'll make a repro. 
Maybe the fact that my project was reimported fixed the issue. 

This is still a really pervasive, destructive problem. I would recommend disabling any undo function until you guys can fix this. Perhaps that would work? We don't need an undo feature if it's going to kill our macros. 

He already mentioned Unity doesn't allow them to disable Undo functionality. Maybe a warning every time you Undo? But tbh this is really silly, that there can't be a way for the user to decide to disable-reenable Undo. Maybe is it possible to change Unity's default Ctrl Z? And set Undo to a custom.. never-used hotkey?


Good news! Thanks to Yuono's report, I believe I have found & fixed the undo bug for good. :D

The fix is v.1.4.9, available now: https://ludiq.io/bolt/download/1.4.9

Thanks everyone for your incredible patience and understanding on this. After a year of not being able to reproduce it, all it took was 1 day of work and 3 lines of code to fix it. Crazy how reproduction steps change everything!

Nope, it's still there :(

MissingMemberException: Failed to find reflected member 'name' on 'Literal':
Ludiq.MemberMetadata.Reflect (System.Boolean throwOnFail) (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Core/Editor/Meta/MemberMetadata.cs:93)
Ludiq.MemberMetadata..ctor (System.String name, System.Reflection.BindingFlags bindingFlags, Ludiq.Metadata parent) (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Core/Editor/Meta/MemberMetadata.cs:19)
Ludiq.Metadata+DigMember.<.ctor>b__0_0 (Ludiq.Metadata parent) (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Core/Editor/Meta/Metadata.cs:1321)
Ludiq.Metadata.Dig[TSubpath,TMetadata] (TSubpath subpath, System.Func`2[T,TResult] constructor, System.Boolean createInPrefab, Ludiq.Metadata prefabInstance) (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Core/Editor/Meta/Metadata.cs:648)
Ludiq.Metadata.Member (System.String name, System.Reflection.BindingFlags bindingFlags) (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Core/Editor/Meta/Metadata.cs:1438)
Ludiq.Metadata.get_Item (System.String name) (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Core/Editor/Meta/Metadata.cs:772)
Bolt.UnitDescriptor`1+<>c__DisplayClass21_0[TUnit].b__0 (Ludiq.Metadata unitMetadata) (at C:/Users/lazlo/Projects/Bolt1/Package/Bolt.Flow/Editor/Description/UnitDescriptor.cs:167)
Bolt.UnitPortWidget`1[TPort].FetchMetadata () (at C:/Users/lazlo/Projects/Bolt1/Package/Bolt.Flow/Editor/Ports/UnitPortWidget.cs:48)
Ludiq.Widget`2[TCanvas,TItem].CacheItem () (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Graphs/Editor/Widgets/Widget.cs:118)
Ludiq.Canvas`1[TGraph].CacheWidgetItems () (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Graphs/Editor/Canvases/Canvas.cs:82)
Ludiq.Canvas`1[TGraph].BeforeFrame () (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Graphs/Editor/Canvases/Canvas.cs:226)
Ludiq.GraphWindow.OnGUI () (at C:/Users/lazlo/Projects/Bolt1/Package/Ludiq.Graphs/Editor/Windows/GraphWindow.cs:533)
System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <567df3e0919241ba98db88bec4c6696f>:0)
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
UnityEngine.UIElements.UIR.RenderChain.Render (UnityEngine.Rect topRect, UnityEngine.Matrix4x4 projection) (at C:/buildslave/unity/build/Modules/UIElements/Renderer/UIRChainBuilder.cs:238)
UnityEngine.UIElements.UIRRepaintUpdater.DrawChain (UnityEngine.Rect topRect, UnityEngine.Matrix4x4 projection) (at C:/buildslave/unity/build/Modules/UIElements/Renderer/UIRRepaintUpdater.cs:66)
UnityEngine.UIElements.UIRRepaintUpdater.Update () (at C:/buildslave/unity/build/Modules/UIElements/Renderer/UIRRepaintUpdater.cs:54)
UnityEngine.UIElements.VisualTreeUpdater.UpdateVisualTree () (at C:/buildslave/unity/build/Modules/UIElements/VisualTreeUpdater.cs:72)
UnityEngine.UIElements.Panel.Repaint (UnityEngine.Event e) (at C:/buildslave/unity/build/Modules/UIElements/Panel.cs:637)
UnityEngine.UIElements.UIElementsUtility.DoDispatch (UnityEngine.UIElements.BaseVisualElementPanel panel) (at C:/buildslave/unity/build/Modules/UIElements/UIElementsUtility.cs:240)
UnityEngine.UIElements.UIElementsUtility.ProcessEvent (System.Int32 instanceID, System.IntPtr nativeEventPtr) (at C:/buildslave/unity/build/Modules/UIElements/UIElementsUtility.cs:78)
UnityEngine.GUIUtility.ProcessEvent (System.Int32 instanceID, System.IntPtr nativeEventPtr) (at C:/buildslave/unity/build/Modules/IMGUI/GUIUtility.cs:179)

Wow! Congrats, amen, and hallelujah! XD And thanks for doing this!

Hopefully some more people test this and verify that indeed macros are safe from The Undo.