[BUG?] Possible GC Issue with FStreamableManager::CheckCompletedRequests

Hi, I think I may have found an issue with FStreamableManager::CheckCompletedRequests.

TL;DR - In the situation where multiple assets are requested for Async loading, it’s possible for one of the assets to be GC’d before the callback (to the original call site) has been executed.

More wordy version - Let’s assume I have three assets I need to load {A, B, C}, I call the following function on StreamableManager:

StreamingManager->RequestAsyncLoad(ItemsToStream, FStreamableDelegate::CreateUObject(this, &UStreamRequest::StreamingCallback));

Each of the assets, {A, B, C} get added to the SteamableManager’s StreamableItems and scheduled for asynchronous loading. An internal callback for each asset deals with the case of that asset loading.

This callback is FStreamableManager::CheckCompletedRequests, which checks to see if all the assets {A, B, C} necessary for the initial request are now loaded (the if (Existing->RelatedRequests[i]->StreamablesReferenced == 0) section) and if they are, triggers the callback (to my “UStreamRequest” object, above).

However, in the case where not all of the assets are ready, this doesn’t happen, and the “just loaded” object (let’s call it {A}) is flagged for unloading. This Unload call may result in the object being GC’d, before all the other assets have finished loading. Hence once the final object has loaded, and the “UStreamRequest” callback is processed, one of the objects ({A} in our case) may not be there.

Is this a known issue? (If so, is there a fix?)
Is this a mis-reading on my part? (If so, is there a mistake I’ve made in how I’m using the StreamableManager?)

Many thanks,
-.

Hey, was it fixed? or maybe you do have a workaround?

Any new insight into this? I believe I might be running into the same thing. Not sure how to approach a resolution as documentation around StreamingManager is super scarce.