FStreamableManager GStreamableDelegateDelayFrames Cancel issue

We have an issue with FStreamableManager with regard to GStreamableDelegateDelayFrames.

The delay before the ‘complete’ delegate fires means that it’s possible to be in a scenario where we’re attempting to cancel the streaming of a target, but at that point it’s already “pending completion” and in the midst of the delay waiting to fully complete (see PendingDelegates). If you try to cancel a target at this point it won’t let you, it has to let the completion play out.

This means that if you’re tracking the FStreamableHandle’s for your targets and you want to cancel them from loading; your code can’t assume that FStreamableManager will be finished with the targets after calling Cancel on them, as there may be some caught up in the DelayFrames waiting to complete, so you have to allow any PendingDelegates there may or may not be to play out during the upcoming frames, and don’t perform any further related cleanup operations until they have - which is not that easy to ascertain.

Our current workaround is to expose FStreamableDelegateDelayHelper’s FlushDelegates method via FStreamableManager and call it prior to performing any cancel. This ensures that any delegates that are pending firing ‘complete’ do so prior to us trying to perform a cancel, that way we can know that after the cancel is performed on all the targets that there won’t be any unexpected targets completing when we expect the system to be cleared of them.

The down side to this is that we can’t just flush the target we’re attempting to cancel (we have to flush all [without more work]), and we have to be careful that our ‘complete’ listener can handle dealing with the complete callback after possibly trying to initiate a cancel.

Ideally, imo, calling Cancel should perform the cancel callback and remove the completion delegate from the PendingDelegates array so that it doesn’t fire - however I’m not sure how that could factor in with releasing any object pointers the streamer may be holding on to, but it does make more sense to call Cancel immediately rather than Complete in ‘x’ frames time.

Andrew