Why is "XR Plugin Management Editor Work Queue" holding my editor hostage on basically every domain reload?

Hello, for the past few months every single time that I open the editor, or enter / or exiting play mode – I get this incredibly persistent popup from XR.Management.EditorWorkQueue running some code from XR.Management.Legacy.XRLegacy (the popup truncates the rest)… which always locks up the editor due to a seperate incredibly persistent bug with the package manager where the package list fails to load:

This despotically evil pop up occurs every single time that I open the editor; normally 2-4 times in succession (finishing and the popping up again for no discernable reason). Every single time this “design choice from hell” execute (performs the way it was intended) it lock up the editor 100% for between 5-25 seconds when it (very rarely) succeeds refreshing the package list.

For the past several weeks for me it’s also started happened every single time I first enter play mode after starting the editor as well; normally hanging the editor 1-2 times for up to a 30-60 sec before acting normal after. Before this I would only see this happening when exiting / entering / or (also very often when recompiling any scripts).

Whenever it does fail to load the package list (about 95% of the time) I get this warning message after 30 sec: : “XR Plug-in Management Warning: Timeout trying to get package list after 30s. UnityEditor.EditorApplication:Internal_CallUpdateFunctions ()”

Warning 30 Sec Timeout

Of the 95% of the time when it fails, my best guess is that 80% of the these times the above warning mercifully stops the loading bar / editor lockup from XR management… However for me the other 20% of the time when the above warning of a timeout does not register with the loading bar which invoked it after 30 sec, and it continues to hold up the editor anywhere between between 1-3 minutes, before closing, reloading the loading bar again again after half a second, or continuing on like it should. Often I loose all self control at this point and force close the editor in Task Manager, therefor invoking this entire process again.

I know the root cause of this is that unity’s package manager’s incredibly brittle login/package refreshing logic. What’s even weirder for me is that this underlying package refresh bug DOES NOT effect the package manager’s ability to load the list of assets I’ve purchased on the asset store— It only effects Unity 6’s ability to update the free, basic, included, officially supported, 100% core required, packages.

For refrence I’m using 6.0.21f1 (today’s release, with all of my used unity packages also being on the most recent versions).

A few questions)

  1. Why does the work queue’s querying the package list need to run as a “hold on (busy}” editor lock instead of just a background task? Particularly because “XR.Management.EditorWorkQueue” really sounds like it should be a background task like shader compilation.

  2. Why does XR.Management.Legacy.XRLegacy even access the package list? Please make it stop doing this! I cannot fathom a reason why it would need to run on domain reload – really only on initial setup of the project, just like the “rules-and-regulations” which are run when you first start-up the current VR Core demo scene.

  3. Why is the Package Manager so bad at loading the free packages list? Why does it take any time at all? I cannot think of a single reason it should require a login under any circumstance to view the included packages list. / This should be just as fast as loading any public repository on github.

10 Likes

I’m having the same issue. It’s become unbearable to use Unity in this state. I don’t get the Warning stuff, just the annoying popup that takes 30 seconds each time I make a code change.

What I ended up doing was changing this file directly:

\Library\PackageCache\com.unity.xr.management@4.4.0\Editor\Legacy\XRLegacyUninstaller.cs

By the line 80, right after the method static XRLegacyUninstaller(), I inserted a new line with return;

When saving the code Unity will complain that you’re modifying a package file, so be aware that changes may be lost depending on package changes.

I didn’t have time to research the issue further, I just wanted to get rid of waiting for nothing. So I know this isn’t a proper solution, but until Unity provides us with a better fix, it might help you guys.

8 Likes

Thanks for that, at least it is an easy work around until Unity pull their finger out. Has anyone logged this as a bug?

2 Likes

No I don’t believe anybody has reported the bug yet, or at least they haven’t come to talk about it here. @rcalabrezi Thank you for this temp fix! It has been an absolute lifesaver.

1 Like

Having the same issue with Unity 6.023

1 Like

amazing work! thanks!

1 Like

Thanks for the fix. We have been going crazy over this!

1 Like

Hi! this is still happening in Unity 6.0.34f1.

I looked a bit more into it as it was driving me crazy and it seems by adding “ShouldQueryLegacyPackageRemoval” to ProjectSettings/XRPackageSettings.asset it will stop doing the query. The flags are unintuitive, they are added once the removals are completed sucessfully…

This seems to be permanent and version control friendly unlike the previous mentioned workaround. Hurray!

12 Likes

Thank you so much!

Does not work for me. Unity version 6000.0.36f1

1 Like

This is working great for me! In unity 6.0.13f1

This still happens, even in the latest version. I don’t think anyone has reported it as a bug (“XR recompiles are slow”.. ?).

It would be great to get this addressed, it is unjustifiable and must be a bug. Waiting anywhere from 10 - 90 seconds to get recompiles to finish just because XR needs to verify there’s no legacy packages to uninstall is definitely bad. There are certainly more appropriate ways to evaluate something like that.

Editing the package as a workaround is an unreliable hack, but does seem to work.

1 Like

Does not work for me… Unity version 6000.0.40f1

XRPackageMetadataStore.cs, line666 RebuildCache()
If I disable this method, fixed.

It works! 6000.2.2f1

1 Like

This bug had made me feel 40% closer to obsolete because every single code decision I made all day, every day, week after week, was followed with a dozen false starts. I spent this whole time assuming Unity’s compiler was just hyper fragmented and torturing me with sloppy loading popups.

Unity would appear to be done, so I’d grab the mouse and–BLAM! I’d set my head down and wait for three more burps then, seeing nothing happening, I’d grab the mouse–POW! Gotcha. I had gotten into the habit of moving my mouse back and forth over the file browser or scene hierarchy to use the presence or absence of highlights to tell me if Unity was truly done slapping my computer in circles.

Its like trying to read a book but every time you turn a page a flash-bang goes off on the next page so you have to wait to read it only to have between three and ten more flash-bangs go off at random before you’re allowed to read, with pauses between each just long enough to get through half a paragraph. Maintaining a train of thought against an onslaught of unrelated pop-ups was so draining.