Ensures fire in UMVVMView::InitializeSourceBindings and UMVVMView::SetSourceInternal - possible re-rentrant bug?

Is UMVVMView::InitializeSources safe to call when the global ViewModel collection can change on the same tick?

We’re seeing client ensures fire in UMVVMView::InitializeSourceBindings and UMVVMView::SetSourceInternal with the message “The source X should be valid.” The ViewSource.Source pointer (a UPROPERTY TObjectPtr) is null while the corresponding ValidSources bitfield bit is set, causing the bIsPointerValid == bIsBitfieldValid check to fail.

The sequence we believe triggers it:

  1. A widget using a global-collection ViewModel source is pushed to a layer stack via PushWidgetToLayerStackAsync.
  2. A large async load completes on the same tick, which updates the global UMVVMViewModelCollectionObject and fires OnCollectionChanged.
  3. HandleViewModelCollectionChanged is invoked reentrantly during InitializeSourceBindings, because InitializeSources subscribed to OnCollectionChanged at the top of the function, before sources or bindings were initialized.
  4. HandleViewModelCollectionChanged calls SetSourceInternal, which calls UninitializeSource, clearing ValidSources and nulling Source mid-initialization.
  5. InitializeSourceBindings then reads the now-inconsistent state and fires the ensure.

Our proposed fix is to move the OnCollectionChanged subscription to after all sources, bindings, and extensions are initialized — immediately before bSourcesInitialized = true — so the handler can only fire once the view is in a fully consistent state. Is this the correct approach, or is there a reason the subscription must happen before source initialization?

[Attachment Removed]

Hi,

Moving the delegate registration to the end makes sense, I don’t see any potential problems. I’ve checked this in at CL# 54926030. Thanks!

[Attachment Removed]

Thanks, I appreciate the quick response!

[Attachment Removed]