Okay, I looked again and that makes sense for the same flow. Further, it is due to a bug that still exists in head. The bug does not cause a problem in head because we’re not doing the second lookup because we have 38318389 instead, but the data is incorrect, just never read.
RemoveCookedPackages recreates PackageNameToIndex, getting the PackageName to use as the key in PackageNameToIndex from CookedPackagesInfo[N]. When cooking iteratively, for packages that were previously cooked, CookedPackagesInfo[N].PackageName is set on line 538 when constructing the CookedPackagesInfo from the downloaded Oplog, so those packages are readded to PackageNameToIndex correctly. But for new packages discovered in the current cook, when we add a new element to CookedPackagesInfo on line 829, we do not set the PackageName on it. And we don’t set it down below on lline 1068 either.
Change line 829 to store the PackageName in the new CookPackageInfo:
if (CommitEventArgs.EntryIndex == PackageStoreEntries.Num()) { PackageStoreEntries.Emplace(); // New Code // CookedPackagesInfo.Emplace(); CookedPackagesInfo.Emplace(CommitInfo.PackageName); // End New Code // BEGIN ARCHETYPE CHANGE (DVT-1134) // DVT: https://archetype-games.atlassian.net/browse/DVT-1134 // Extra new code in his block beyond the preport of 37590157. Suggested by Epic at // [Content removed] check(PackageStoreEntries.Num() == CookedPackagesInfo.Num() && CookedPackagesInfo.Num() > CommitEventArgs.EntryIndex); // END ARCHETYPE CHANGE (DVT-1134) }