Cook fails only when multiprocess cook with imports in external packages marked as unsaveable

Development Pipeline & Plugins
, ,
1

This question was created in reference to: [FArchiveGatherExternalActorRefs incorrectly gathering references in specific [Content removed]

2

Steps to Reproduce
Several of our scheduled cooks have been intermittently failing on packages that appear to be unable to be saved due to “references to import marked as unsaveable.” Although this issue appears to have been fixed a few months ago (we integrated the CL back in august), we encounter it under different conditions:

The exported object has only one reference to the imported object (not two where one is “editor only”). Second, the problem only occurs when cooking with more than one cook worker. When the problem is encountered, often the first cook after a sync to head, the problem disappears on its own when cooking a second time. When UGS is configured to use only a single cook worker, the problem never occurs. We’ve seen the problem when cooking for Windows and consoles.

Nothing in particular stands out when analyzing the problematic references. The constructs vary in form but are similar: An actor referencing another actor via a property. Sometimes native, sometimes Blueprint.

Looking for ideas or possible solutions that could help.

3

What is the text of the log message? Are the export and import both displayed or is one of them Unknown?

These two statements are the possible messages and they have different causes:

// Line 559: Both actors are in the same UWorld
"Can't save %s: export (%s) has a reference to export (%s) which still has its external package set to (%s)"
 
// Line 567: One of the actors is in a different UWorld than the other
"Can't save %s: export (%s) has a reference to import (%s), but the import is in ExternalPackage (%s) which was marked unsaveable."

“Which was marked unsaveable” only occurs when one of the actors is in a different UWorld. Are both actors in the same UWorld? Are either of the source or target actors in a level instance that is embedded into the level?

4

Export and import are displayed. These are two OFPA actors in a World Partition map. No data layer involved. What is interesting though is that for most of our failing cases, the export originally came from a Level Instance, which was broken down into the world partition map. Most of the time, but not always, the import was created directly in the world partition map and then referenced. Example below:

Can’t save REDACTED\6S7ITBII9YFNW8T4KT4BNYLNK.UMAP: export (/REDACTED/_Generated_/6S7ITBII9YFNW8T4KT4BNYLNK.REDACTED:PersistentLevel.REDACTED_C_UAID_4CD717A34F34F26102_1346314280) has a reference to import (/REDACTED:PersistentLevel.REDACTED_C_UAID_E8CF839E68E85D8D02_1345252072), but the import is in ExternalPackage (/REDACTED/6/QZ/6LTQ6XJNQPUA6OW4LGC0EZ) which was marked unsaveable.

5

Hi Etienne, thanks for the information. We haven’t encountered this issue internally under similar circumstances to what you’re describing, so I don’t have an answer for you right away. I’ll get back to you once I have more information or additional questions.

6

Hi Etienne,

I’ve poked around that code, but I don’t have any new leads at the moment.

I wonder if you’ve gotten any new information in the meantime, or if you’ve managed to find a more reliable way to reproduce this issue?

Thanks,

Andrzej

7

Thanks for reaching out. The only new information we have is that we once reproduced it with a single cook worker. Cleaning the workspace through UGS solved the issue but I can’t tell whether or not the issue would have vanished by itself on the second cook, like it does in a multi cook worker context.

​

I plan to dig into this a bit further if time allow in the upcoming weeks. I’ll come back here if I find something meaningful. Thanks again!​

8

One guess that I had, based on the fact that it happens only on the first cook, is that maybe garbage collection is involved somehow. The first cook after a sync will encounter some DDC builds that need to be executed, and therefore take longer and give more opportunities for GC to occur. It’s just a guess, but when you try to repro and look into this again maybe you can try forcing garbage collection more often to see if you can make it more likely to repro.