Niagara Data Interface "Errors and Warning" section on Module Details not updating when error messages change

This is a regression: it worked correctly up to UE 5.5, but not in 5.6 or mainline latest. Possibly caused by CL 40093049.

Class UNiagaraDataInterface provides virtual method GetFeedback(), which allows the implementation to fill arrays containing errors, warnings, and information messages based on validation checks. When an error or warning is produced, the Details Panel for the Niagara Module that makes use of the Data Interface will display a generic section "Object has errors" (or "Object has warnings"), plus a customized section "Errors and Warnings" that list the detected issues and possibly contains "fix" buttons.

The validation checks performed by GetFeedback() can depend on data external to the Data Interface itself. For example, a Static Mesh Interface often needs to check if the linked static mesh asset has "allow cpu access" enabled. Up to UE 5.5, changing such external data caused the "Errors and Warnings" section to be updated correctly. Beginning on UE 5.6, however, the section seems to only be updated when a property of the Data Interface itself changes. This can lead to errors still appearing when they were already resolved (e.g. allow cpu access was already turned on but the error did not go away), or to error explanations not appearing at all when a condition triggers an issue (e.g. allow cpu access was turned off, section "object has errors" appeared, but section "Errors and Warnings" did not appear with the explanation and fix button).

(more info on the "callstack" field)

1. Create and open a new Niagara System based on template "SingleLoopingParticle"
2. On the emitter stack, add a new "Static Mesh Location" module to the "Particle Spawn" stage
3. On the details panel for the new module:
3.1. Note the presence of sections "Object has warnings" and "Errors and Warnings"
3.2. Set "Default Mesh" to "/Engine/BasicShapes/Cone"
3.3. Note the presence of sections "Object has errors" and "Errors and Warnings"
3.4. Do NOT click the "Fix Now" button. Instead, double-click the cone asset to open it
4. Keep the Static Mesh Editor and the Niagara Editor simultaneously visible
4.1. On the Details Panel of the Static Mesh Editor, check and uncheck "Allow CPUAccess"
4.2. On the Details Panel of the Niagara Editor, note that section "Object has errors" gets hidden and shown correctly, but that section "Errors and Warnings" doesn't ever disappear.
5a. Click Niagara's "Fix Now" button. Section "Errors and Warnings" disappears.
5b. Alternatively, close and reopen the Niagara Editor while "Allow CPUAccess" is checked. Section "Errors and Warnings" disappears.
6. Repeat step 4. Note that, this time, section "Errors and Warnings" doesn't ever appear, leaving the user without the error description.

Note: The same problem happens with any UNiagaraDataInterface that reports errors through the GetFeedback() (or GetErrors()) function.
Note: This problem did not happen up to UE 5.5

The error list displayed in the Details Panel seems to be refreshed by calling function UNiagaraDataInterface::RefreshErrors(). This is called, for example, by UNiagaraStackObject::NotifyPostChange() when the "fix" button is pressed:

FNiagaraDataInterfaceCustomNodeBuilder::OnErrorFixTriggered()
UNiagaraStackObject::NotifyPostChange(const FPropertyChangedEvent & PropertyChangedEvent, FProperty * PropertyThatChanged)
UNiagaraDataInterface::RefreshErrors()
FNiagaraDataInterfaceCustomNodeBuilder::OnRefreshErrorsRequested()
FDetailItemNode::GenerateChildren()

Previously, UNiagaraDataInterface::RefreshErrors() was also called inside UNiagaraStackObject::RefreshChildrenInternal(). This was triggered, for example, when the user selected the module on the emitter stack:

SNiagaraOverviewStack::OnSelectionChanged(UNiagaraStackEntry * InNewSelection, ESelectInfo::Type SelectInfo)
UNiagaraSystemSelectionViewModel::UpdateSelectedEntries(const TArray<UNiagaraStackEntry *,TSizedDefaultAllocator<32>> InSelectedEntries, const TArray<UNiagaraStackEntry *,TSizedDefaultAllocator<32>> InDeselectedEntries, bool bClearCurrentSelection)
UNiagaraSystemSelectionViewModel::UpdateExternalSelectionState()
UNiagaraStackEntry::RefreshChildren()
UNiagaraStackObject::RefreshChildrenInternal(const TArray<UNiagaraStackEntry *,TSizedDefaultAllocator<32>> & CurrentChildren, TArray<UNiagaraStackEntry *,TSizedDefaultAllocator<32>> & NewChildren, TArray<UNiagaraStackEntry::FStackIssue,TSizedDefaultAllocator<32>> & NewIssues)
UNiagaraDataInterface::RefreshErrors()

... or on Tick() after a relevant external data was changed:

FPropertyRowGenerator::Tick(float DeltaTime)
FDetailLayoutBuilderImpl::Tick(float DeltaTime)
FDetailCategoryImpl::Tick(float DeltaTime)
FDetailCategoryImpl::RefreshTreeInternal(bool bRefilterCategory)
FPropertyRowGenerator::UpdateDetailRows()
TMulticastDelegate<void __cdecl(void),FDefaultDelegateUserPolicy>::Broadcast()
TMulticastDelegateBase<FDefaultDelegateUserPolicy>::Broadcast()
V::TBaseUObjectMethodDelegateInstance::ExecuteIfSafe()
UE::Core::Private::Tuple::TTupleBase<TIntegerSequence<unsigned int>>::ApplyAfter(void(UNiagaraStackObject::*)() &)
Invoke(void(UNiagaraStackObject::*)())
UNiagaraStackObject::PropertyRowsRefreshed()
UNiagaraStackEntry::RefreshChildren()
UNiagaraStackObject::RefreshChildrenInternal(const TArray<UNiagaraStackEntry *,TSizedDefaultAllocator<32>> & CurrentChildren, TArray<UNiagaraStackEntry *,TSizedDefaultAllocator<32>> & NewChildren, TArray<UNiagaraStackEntry::FStackIssue,TSizedDefaultAllocator<32>> & NewIssues)
UNiagaraDataInterface::RefreshErrors()

This changed with CL 40093049 (message: "StackObject now calls RefreshErrors on the DataInterface on PostChange, and no longer in RefreshChildrenInternal. This fixes an issue where two pieces of UI code would constantly tell each other to refresh"), which is a likely cause of the current behavior. Simply adding back the call to DataInterfaceObject->RefreshErrors() restores the correct update behavior, but might bring back the problem that the CL attempted to address.