We are running into an issue where, during a commandlet, we load some assets that have ExternalReadDependencies. During the external read process, we run validation which triggers a TSoftObjectPtr to be loaded on demand via `TSoftObjectPtr::Get`. This triggers the assert mentioned in the subject line.
Internally we’ve been able to fix this by adding the following code directly before the call to `Package->ProcessExternalReads` in `FAsyncLoadingThread2::ProcessAsyncLoadingFromGameThread`:
This feels like it may have just been an oversight given how recent the `GPlayInEditorID` changes are. It also seems strange to even need to worry about `GPlayInEditorID` in the context of a commandlet. That said, we wanted to check in with you to determine if this is an appropriate fix or could cause unintended side effects.
Loading assets during ProcessExternalReads has never been tested/supported, I can see it easily cause deadlocks or partial loads if the asset you end up loading has a dependency on the package already loading on the stack.
Having said that, the fix that you propose is consistent with the other PlayInEditorLoadingScope we put in place in other nodes.
GPlayInEditorID is not used in command-let, but the protection we put in place to detect missing scopes apply to WITH_EDITOR code, so it trips even for command-let. That’s normal behavior.
Thanks for the insight. I think we’re probably safe from the deadlock scenario that you’ve called out in the particular case we’re seeing this. But given you’ve called that out, we’ll probably just fix up the `GPlayInEditorID` in our code rather than adding this currently rather than adding the PlayInEditorLoadingScope to this new place in the async loading thread so we can evaluate any other instances like this if they come up.