Branch/CL: Release-5.7 @ Epic CL 50871544 (5.7.4). Also present in //UE5/Main @ CL 52530890.
File: Engine/Source/Developer/AssetTools/Private/AssetRenameManager.cpp
FAssetRenameManager::AutoCheckOut, ~lines 1237-1245.
SUMMARY
The Warning intended for the FCheckOut failure case is emitted on the success branch instead. Two consequences:
1. Every successful auto-checkout during an asset rename logs a spurious Warning, whose text (“was not not able to auto checkout”) reads as a failure.
2. A genuine FCheckOut failure logs nothing at all; the function returns false with no diagnostic.
CURRENT CODE
if (!bSomethingFailed && PackagesToCheckOut.Num() > 0)
{
bSomethingFailed = (SourceControlProvider.Execute(ISourceControlOperation::Create<FCheckOut>(), PackagesToCheckOut) != ECommandResult::Succeeded);
if (!bSomethingFailed)
{
UE_LOG(LogAssetTools, Warning, TEXT(“FAssetRenameManager::AutoCheckOut: was not not able to auto checkout.”));
PackagesToCheckOut.Empty();
}
}
bSomethingFailed is true only when Execute() does not return Succeeded, so this block runs only when the checkout SUCCEEDED, yet it warns.
WHY THIS LOOKS LIKE AN INVERTED CONDITION
The same function has three other failure paths, each logging a Warning naming the reason: ~1223 (IsCheckedOutOther), ~1228 (!IsCurrent), ~1257 (IsReadOnly). The line at ~1242 is the only one of the four on a success path, and the only one whose wording contradicts its branch. PackagesToCheckOut.Empty() is correct where it is, so the log line, not the condition, appears to be what was misplaced.
REPRO
1. Project with revision control enabled (reproduced with Perforce).
2. Rename/move an asset via FAssetRenameManager on a path where auto-checkout is used (bAutoCheckout == true), e.g. a commandlet-driven rename.
3. Ensure the packages are at head and not checked out by anyone, so the checkout genuinely succeeds.
4. Observe the log.
Seen in a commandlet that renamed assets under Perforce. The run succeeded (all assets moved, exit code 0) but reported “Success - 0 error(s), 1 warning(s)” with this as the only entry:
LogAssetTools: Warning: FAssetRenameManager::AutoCheckOut: was not not able to auto checkout.
EXPECTED VS ACTUAL
Expected: success logs nothing at Warning severity, and a failed FCheckOut logs a Warning explaining the failure, consistent with the other three paths. Actual: the reverse - success warns, failure is silent.
IMPACT
Mostly log noise, but disproportionately disruptive for automated pipelines. Teams running commandlets under a zero-warnings policy get a spurious warning on every successful rename, and the misleading wording sends people investigating a source control problem that did not occur. It also leaves the real failure path with no diagnostic at all.
SUGGESTED FIX
bSomethingFailed = (SourceControlProvider.Execute(ISourceControlOperation::Create<FCheckOut>(), PackagesToCheckOut) != ECommandResult::Succeeded);
if (!bSomethingFailed)
{
PackagesToCheckOut.Empty();
}
else
{
UE_LOG(LogAssetTools, Warning, TEXT(“FAssetRenameManager::AutoCheckOut: was not able to auto checkout.”));
}
Return value and list-clearing semantics are unchanged. The 5.8 release branch uses UE_LOGF rather than UE_LOG, but the control flow, and therefore the fix, is the same.