"Unexpected transport error from import worker"

[Wrymnn]

Nobody is getting these?

There is no stack trace, nothing, I can’t believe why editor developers leave error logs like this, who is it helping?

They are always spamming the console like crazy, in every project, unity 6000.0.40, or previous ones.
There can be hundreds of these literally. They are present for all our team members, yet I dont really see any posts on this issue.

They are very random and not sure whats the repro steps, thats why its not a bug report yet.
Maybe somebody figured this out?

[bugfinders]

havent seen it myself

[CodeSmile]

As usual, try deleting the Library folder to see if that makes it go away. “End of file” could indicate a corrupt file, possibly an artifact in the Library.

Since you work in a team, ensure everyone is using the exact same Unity version down to the patch level (6000.0.40f1). Various issues can arise if devs on a team don’t give any consideration to versioning and everyone updating at the same time, including data corruption.

Although the details vary, there are several mentions of this kind of error.

[Wrymnn]

So only way is to basically keep deleting the Library because we delete library regularly due to other unity issues, but this error keeps happening.

We all use the same unity version with proper version controlling, so nothing like bad version gets through.

Also yes there are topics for this kind of error, but many of them mention like “its fixed in 6000.0.22”, while clearly it is not
There is even issue tracker for this: Unity Issue Tracker - "Unexpected transport error from import worker 0" error is thrown when importing an asset marked as fixed…

[Kurt-Dekker]

Are you using some kind of cloud file sharing like one drive or google drive? Those types of things generally won’t work in Unity.

[CodeSmile]

@Wrymnn

due to other unity issues

What are these?

I’m guessing all of these are related, and something keeps bonkering your Library or even project assets.

Try disabling parallel imports for a while since any custom asset importer must take the necessary steps to be multithreading compatible (outlined in the manual) and I’m guessing that many of the store asset or custom importers don’t concern themselves with that.

I’m also consistently peeving about proper use of the AssetDatabase (primarily: don’t Refresh, use ImportAsset; don’t SaveAssets, use SaveAssetIfDirty). Usually it’s just a matter of performance and playing nice with your users but occassionally it could also corrupt assets.

For instance you cannot use ADB methods in static ctors, InitializeOnLoad methods and all but one AssetPostprocessor method (OnPostprocessAllAssets is where you can use it). Unity started logging these as errors in Unity 6 though but perhaps not all of them.

[Wrymnn]

One of the issues was this (the corrupt file from VFX asset)

Is this the state of editor for Unity 6?

We finally solved it, but still I presume this is unity bug. We traced it to one of assets we bought weeks ago (there problems started) that uses VFX shader graph. When the unity kept hanging forever, even during player build, it was always this error in logs: Aborting batchmode due to fatal error: The file 'VirtualArtifacts/Primary/f72b49844b3860c49a84722f2a664a39' is corrupted! Remove it and launch unity again! [Position out of bounds!] The GUID we traced to one of .vfx assets. As soon as…

The stuck unity processes is still an issue.

@CodeSmile

Try disabling parallel imports for a while since any custom asset importer must take the necessary steps to be multithreading compatible (outlined in the manual) and I’m guessing that many of the store asset or custom importers don’t concern themselves with that.

is this only for test to check if this may be causing the issue? How can we investigate what is causing it even if errors stop after this? As we need the parallel imports for real development, otherwise it will be extremely slow I presume.

@CodeSmile

I’m also consistently peeving about proper use of the AssetDatabase (primarily: don’t Refresh, use ImportAsset; don’t SaveAssets, use SaveAssetIfDirty). Usually it’s just a matter of performance and playing nice with your users but occassionally it could also corrupt assets.

yes we do use these, mainly

EditorUtility.SetDirty(this);
AssetDatabase.SaveAssetIfDirty(this);

only from within AssetPostprocessor.OnPostprocessAllAssets() though.

Then we use

AssetDatabase.FindAssets
AssetDatabase.GUIDToAssetPath
AssetDatabase.LoadAssetAtPath

from [InitializeOnLoadMethod] (doesnt log any error here).

Our aim was to go over all the scriptable objects after each code recompile, or project startup. Don’t know of any alternative to InitializeOnLoadMethod unfortunately.

[Wrymnn]

No, its only git.

[CodeSmile]

@Wrymnn

is this only for test to check if this may be causing the issue? How can we investigate what is causing it even if errors stop after this?

Yes for testing. If the issue goes away, check how much your project actually benefits from parallel imports in everyday use. Often its negligible. And then you should inspect all asset importers. The manual mentions the caveats I think.

@Wrymnn

Don’t know of any alternative to InitializeOnLoadMethod unfortunately.

I’m not sure if InitializeOnLoadMethod isn’t just fine. But it’s easy to bypass this by wrapping the code inside into:

EditorApplication.delayCall += () =>
{
    // the original code goes here
}

This delays execution until after the first editor update. The callback doesn’t need to be unregistered, it’s automatically removed every time a delayCall gets invoked.