Releasing a AsyncOperationHandle doesn't invalidate it

[sharp topaz]

`if (spriteHandle.IsValid()) {
Addressables.ReleaseInstance(spriteHandle);
}

// spriteHandle.isValid() is still true here so the handle will get released again
if (spriteHandle.IsValid()) {
Addressables.ReleaseInstance(spriteHandle);
}`

I would expect that releasing an AsyncOperationHandle would make that specific handle not valid anymore (which of course is not possible because AsyncOperationHandle is a value type). However, from a memory management perspective I would like to be able to release a handle haphazardly, so that I don't hold on to unneeded memory.

Am I overthinking here or am I missing something?

[glass saffron]

releasing the last instance should invalidate the internal handle, are you sure there's not more than one reference? it'll stay valid until the ref count reaches 0

[sharp topaz]

I see.

So to confirm: the IsValid() doesnt tell me if that specific AsyncOperationHandle has been released. It just tells me if the actual AsyncOperation and its addressable is still valid and loaded into memory

[glass saffron]

where is spriteHandle coming from in your example? if you call Addressables.InstantiateAsync and then call Addressables.ReleaseInstance on the returned handle, that handle should become invalid immediately

[sharp topaz]

The handle is coming from a Addressables.LoadAssetAsync(spriteReference). For context, the call is coming from a ItemWidget which is part of an inventory screen. The inventory screen has multiple ItemWidget (of course :P), where items can use the same sprite, therefor the Addressables.LoadAssetAsync can be called on the same AssetReferenceSprite

[glass saffron]

ohh, well ReleaseInstance is only meant to be used with prefab instances - if you pass in a handle it actually does the same thing as Release but Release is the correct method to call for non-prefab handles!

so yeah if it's assets rather than prefab instances you're dealing with, it's expected that the asset handles all refer to the same underlying operation