FixupRedirectors is trying to delete regular Blueprint classes

Development Programming & Scripting
, ,
1

We are noticing that the ResavePackages/FixupRedirectors commandlet is sometimes attempting to delete files that aren’t necessary redirectors:

Can't delete redirector [../../../Projects/Meerkat/Content/Gameplay/Action/ActionStates/ActState_Cooldown.uasset], unsaved packages reference it

In editor, this file shows up as a regular Blueprint and not a redirector. After debugging through the commandlet though, we found there is an object redirector in the obj list of this file:

[2026.02.13-10.30.09:732][967]Obj List: outer=/Game/Gameplay/Action/ActionStates/ActState_Cooldown
[2026.02.13-10.30.09:732][967]Objects:
[2026.02.13-10.30.09:862][967]                                                                   Object   NumKB   MaxKB  ResExcKB ResExcDedSysKB ResExcDedVidKB   ResExcUnkKB
[2026.02.13-10.30.09:862][967]                      BlueprintGeneratedClass /Game/Gameplay/Action/ActionStates/ActState_Cooldown.ActState_Cooldown_C   2.40    3.23    0.00      0.00      0.00      0.00
[2026.02.13-10.30.09:862][967]                    BlueprintGeneratedClass /Game/Gameplay/Action/ActionStates/ActState_Cooldown.SKEL_ActState_Cooldown_C   2.28    3.15    0.00      0.00      0.00      0.00
[2026.02.13-10.30.09:862][967]                              Blueprint /Game/Gameplay/Action/ActionStates/ActState_Cooldown.ActState_Cooldown   2.71    2.71    0.00      0.00      0.00      0.00
[2026.02.13-10.30.09:862][967]                    ObjectRedirector /Game/Gameplay/Action/ActionStates/ActState_Cooldown.Default__ActState_Cooldown_C_1   0.06    0.06    0.00      0.00      0.00      0.00

Resaving this file (or it’s referencers) does not remove this redirector, which means the commandlet will try to resave all of this file’s referencers every run which isn’t ideal.

This is affecting quite a few files for us, so it’s not a isolated issue, though it’s not clear to me how the object redirector gets there in the first place. The only way I’ve found that removes the redirector is either duplicating the blueprint and deleting the old one, or running the following to re-save without redirectors:

Redirector->Rename(nullptr, GetTransientPackage(), REN_DontCreateRedirectors);

I’m wondering if it’s a known issue that this can happen, and whether it’s safe to force a re-save without these redirectors? (e.g. are they perhaps used under the hood for anything?)

[Attachment Removed]

2

Hey Joseph,

apologies for the long wait. This has been passed around internally a bit, but no team really wanted to pick it up.

I’ve done some research, and we’ve only seen a similar case once, which was reported a few years ago.

In this case renaming a LevelSequence could somehow cause this to happen, where a package ended up with both data and a redirector.

However in that instance the commandlet would actually delete those packages.

Since you have what looks like other Blueprints in your package this is unlikely to be the same cause.

In general, the expectation is that when a package is renamed, only the redirector remains in the package and no other public objects.

The ResavePackagesCommandlet detects this indirectly through the reference in this case.

Have you checked if the references come from outside the package?

That could be an indicator of some kind of failed rename operation.

You’d need to verify whether there’s a new/valid asset somewhere that the redirector points to, and if not, removing it is likely the best choice to restore the asset.

Since we haven’t seen this on a larger scale we don’t have any educated guesses about the cause, but some kind of renaming operation is possible.

Kind Regards,

Sebastian

[Attachment Removed]

3

> We ended up fixing these up by adding an additional check to the ResavePackagesCommandlet that detects and deletes this reference like you mentioned and that’s fully resolved the issue

Perfect, glad to hear you were able to sort it out without any further issues!

> For my own understanding, does this mean the above scenario where a package contains both data and an redirector is not expected? e.g. It should have left an redirector file in this case that points to a data-only package?

Yes, that’s correct. Redirectors should only ever exist instead of the previous data, never in the same package with it.

Cheers,

Sebastian

[Attachment Removed]

4

Hello - Thanks for looking at this!

The references are all on the same package in this case (e.g. DestinationObject on the redirector contains the path to the same asset that the redirector belongs to). Upon further investigation, we did find that all the problematic assets seemed to be related to the same CL where we migrated a lot of content so I agree that this is potentially due to a failed rename/resave operation when that happened.

We ended up fixing these up by adding an additional check to the ResavePackagesCommandlet that detects and deletes this reference like you mentioned and that’s fully resolved the issue:

if (Redirector && Redirector->DestinationObject && Redirector->DestinationObject->GetOutermost() == RedirectorPackage)
...
Redirector->Rename(nullptr, RedirectorPackage, REN_DontCreateRedirectors);

[Attachment Removed]

5

| In general, the expectation is that when a package is renamed, only the redirector remains in the package and no other public objects.

For my own understanding, does this mean the above scenario where a package contains both data and an redirector is not expected? e.g. It should have left an redirector file in this case that points to a data-only package?

[Attachment Removed]