Addressables.InitializeAsync throws exception when I 'yield return', but not if I await the Task

Unity Engine
1

Hi there

The follow code throws an exception when attempting to access the result:

    IEnumerator Start()
    {
        Caching.ClearCache();

        var iResourceLocatorOp = Addressables.InitializeAsync();
        yield return iResourceLocatorOp;
        Debug.Log(iResourceLocatorOp.Result);
    }

Exception: Attempting to use an invalid operation handle

Callstack

UnityEngine.ResourceManagement.AsyncOperations.AsyncOperationHandle1[TObject].get_InternalOp () (at Library/PackageCache/com.unity.addressables@1.6.2/Runtime/ResourceManager/AsyncOperations/AsyncOperationHandle.cs:186) UnityEngine.ResourceManagement.AsyncOperations.AsyncOperationHandle1[TObject].get_Result () (at Library/PackageCache/com.unity.addressables@1.6.2/Runtime/ResourceManager/AsyncOperations/AsyncOperationHandle.cs:146)
LoadTesting+d__2.MoveNext () (at Assets/Content/Scripts/GameSpecific/Runtime/LoadTesting.cs:19)
UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <23e371e9422742b6a92a9f9bfb37a189>:0)

But the following code does not:

    async void Start()
    {
        Caching.ClearCache();

        var iResourceLocator = await Addressables.InitializeAsync().Task;
        Debug.Log(iResourceLocator);
    }

I am not sure what I am doing wrong.

1 Like
2

Bump

3

I’ll kick this over to the team for some guidance. Which version of Addressables are you using?

4

After using Addressables for about two month I find that it requires way too much deep understanding of the inner workings of it’s classes to be able to use it. This just another example. The API is hard to understand, too fragile and doesn’t even cover some obvious, basic use cases (like getting download progress or operation progress % that actually makes sense and not just a simple average). And the worst of it all is occasional bugs in the system that often make you confused as to whether this is your mistake or developer’s mistake.

In your case it seems the problem is similar to the issue I’ve stumbled upon in my last thread. InitializeAsync internally auto-releases the handle upon completion. It means that normally after you’ve “awaited” this handle via IEnumerator interface as you did in first example, the handle is already released and thus - not usable.

Task interface works because it’s implemented differently and probably captures the result somehow before the handle is released and made invalid. Just another example of bad design - two versions of the same API work differently which is not what user expects…

Ideally they should’ve made only 1 interface (Event callbacks is the best candidate), and support Coroutine and awaitable interfaces via extension methods that would use the first interface under the hood. This way it would be guaranteed to work exactly the same way regardless of the type of interface you use.

2 Likes
5

Agreed. Either release a product that is mostly bug free, easy to understand and thoroughly documented or be available on the forums to answer questions and guide developers. Otherwise who is going to adopt the product? I am so ready to give up on addressables as I’ve been posting here for a week, stumbling my way through the mysterious API, cryptic errors and trying to guess the intended workflows. Haven’t received any help from developers. I don’t mean to sound entitled, it is a free package after all, but I’m just confused on what the plan is here. Do you want the product to be adopted or not?

2 Likes
6

Also it’s not fun when you’ve spent a lot of time debugging the issue, found a way to fix it and presented it to QA, just to be faced with robotic answers like “could you send us a small repro project”. Like WTF it’s not like I’m reporting some obscure crash. I literally tell them what to fix and how and yet it’s not good enough.

1 Like
7

Unsure how i missed your message, I was using 1.6.2.

8

As for the original code it’s like phobos says, the Initialize is auto released. Your call to .Result on the handle in your Debug.Log statement is what’s throwing that error. There’s an optional parameter called autoReleaseHandle. If you need to use that handle pass false into that parameter.

1 Like
9

There is no parameters in the InitializeAsync method… how can we disable handle being auto released?

10

@CameronND , did you solve your problem? I’m using Addressables 1.15.1 with unity 2018.4.26f1 and problem still persist. Do you have a working/stable workflow?

11

Gonna bump this, as I have the same error. I grab the AsyncOperationHandle from the InitializeAsync() method and yield it in some initialization scripts, yet they all throw this exception, stopping these initialization routines.

On my end, the error thrown is due to attempting to get the Status after the yield statement is supposedly finished, saying I can’t request the status of an invalid operation.

My current workaround, and although it is a valid workaround, it doesn’t fit in the current code structure we employ, but anyway, is to call Addressables.InitializeAsync() once, and subscribe one method to its completion event after which will call all necessary data that needs to initialize after this. Preferably, we’d just keep these data structures alone, and let them yield for that initialization handle until done and continue after that.

12

I implement it this way to keep the coroutine flow similar:

_addressablesInitAsyncOperation = Addressables.InitializeAsync();
while (_addressablesInitAsyncOperation.IsValid() && !_addressablesInitAsyncOperation.IsDone)
{
    yield return null;
}
1 Like