RemoveAsyncLoadHandle – Change in Behavior for Ongoing FAsyncPackage::FlushAsyncLoading in UE 5.3

Answer first

RemoveAsyncLoadHandle does not stop an already started FAsyncPackage::FlushAsyncLoading cycle. In UE 5.3 the handle primarily unregisters the async load delegate from FStreamableManager. It is a cancellation of notification, not a hard abort of in-flight I/O or package paging.

• FlushAsyncLoading continues for work that has already been dequeued. RemoveAsyncLoadHandle called during an active flush does not immediately halt the flush.
• OnAsyncLoadCallback is not a cancelled-state callback. The delegate receives a loaded asset reference when the load finishes normally. UE 5.3 does not pass a distinct cancelled flag to the delegate. If the delegate is unregistered before the manager invokes it, the delegate simply does not fire. If unregistered after invocation is scheduled, the delegate can still fire with a valid object.
• A cancel request prevents further notifications for that handle, but it does not prevent the package from finishing the paging/I/O that is already in progress on the async loading thread.

Confirmed facts vs likely explanation

Confirmed: FStreamableManager::RemoveAsyncLoadHandle removes the FStreamableDelegate associated with the handle from the manager’s pending list. The API documentation describes the handle as a way to cancel pending async loads, with no guarantee of immediate termination of work already started.

Likely explanation for UE 5.3: UE 5.3 refactored task ownership in FAsyncPackage. Cancellation timing relative to the flush loop determines outcome:

• Called before the load task is dequeued by FlushAsyncLoading: request is dropped and OnAsyncLoadCallback typically does not fire.
• Called after the task is dequeued but before completion: flush continues to completion, file reads and package paging proceed on the async thread, and the delegate may still be invoked with the loaded object unless it was already removed.

Asset I/O may continue on a separate thread even after delegate removal, making observable completion non-deterministic.

Minimal verification for this case

1. Add UE_LOG inside the async load delegate to capture whether it fires and with what object after RemoveAsyncLoadHandle is called.
2. Log the time of RemoveAsyncLoadHandle vs the time the delegate would fire, and compare to AsyncLoading stats.
3. Run with ?AsyncLoading=1 or enable LogAsyncLoading to see if the request remains in the flush queue after cancellation.

Assumption: you are using the FDelegateHandle returned by RequestAsyncLoad and calling RemoveAsyncLoadHandle on the game thread. If you are using a FStreamableHandle from RequestAsyncLoad, the cancellation semantics differ.

One diagnostic that changes the recommendation: is the handle removed before or after FlushAsyncLoading has already pulled the specific package load task from the queue in the same frame? If you can confirm that timing, you can predict whether the delegate will fire with a loaded object or be suppressed entirely.