Permanent UI thread hang: unbounded ProcessDelayedPropsNodes retry loop when a native-driver animation targets a view absent from the Fabric registry

从 vnext/Microsoft.ReactNative/Modules/Animated/PropsAnimatedNode.cpp 和 NativeAnimatedNodeManager.cpp 开始，跟踪 StartAnimations()、AddDelayedPropsNode() 和 ProcessDelayedPropsNodes()。使用缺失的 Fabric view 重现问题，并验证重试会让出控制权给 message pump，在满足有界条件后停止，并且不再让 UI thread 永久挂起。

Environment

• react-native-windows 0.84.0 (Fabric / composition, Win32 ReactNativeWin32App template)
• Windows 11 26100, x64, Debug and Release both affected

Summary

If PropsAnimatedNode::StartAnimations() runs while its connected view tag is not present in the Fabric view registry (view unmounted, or its native view detached by react-native-screens on an inactive screen), the animated module enters a tight, unbounded retry loop posted to the UI batching queue. The loop runs inside CoreMessaging's queue drain, so the Win32 message pump is never re-entered: the app goes permanently "Not Responding" with one core pinned at 100%. It never recovers.

Root cause

PropsAnimatedNode::StartAnimations() falls back to AddDelayedPropsNode when the view cannot be resolved (PropsAnimatedNode.cpp):

    } else {
      if (const auto manager = m_manager.lock()) {
        manager->AddDelayedPropsNode(Tag(), m_context);
      }
    }

AddDelayedPropsNode immediately re-posts ProcessDelayedPropsNodes() to the UI batching queue (NativeAnimatedNodeManager.cpp#L446-L460):

void NativeAnimatedNodeManager::AddDelayedPropsNode(
    int64_t propsNodeTag,
    const winrt::Microsoft::ReactNative::ReactContext &context) {
  m_delayedPropsNodes.push_back(propsNodeTag);
  if (m_delayedPropsNodes.size() <= 1) {
    winrt::Microsoft::ReactNative::implementation::ReactCoreInjection::PostToUIBatchingQueue(
        m_context.Handle(), [this]() { ProcessDelayedPropsNodes(); });
  }
}

ProcessDelayedPropsNodes() retries StartAnimations(), which fails again and re-enqueues — with no delay, no retry limit, and no yield back to the message pump. Because the re-post lands in the queue currently being drained by Microsoft::CoreUI::Dispatch::UserAdapter::DrainCoreMessagingQueue, the drain never completes and PeekMessage is never called again.

If the view never reappears (e.g. the React component is still mounted so the JS side never drops the animated node, but the native view stays detached), the loop is infinite.

Call stack (spinning UI thread, symbolized from a full dump with the 0.84.0 NuGet PDBs)

Microsoft_ReactNative!Microsoft::ReactNative::NativeAnimatedNodeManager::ProcessDelayedPropsNodes  [Modules\Animated\NativeAnimatedNodeManager.cpp @ 446]
Microsoft_ReactNative!...AddDelayedPropsNode::__l5::<lambda_1>::operator()                          [Modules\Animated\NativeAnimatedNodeManager.cpp @ 457]
Microsoft_ReactNative!Mso::React::MessageDispatchQueue2::tryFunc                                    [Shared\Threading\MessageDispatchQueue.cpp @ 120]
Microsoft_ReactNative!Mso::QueueService::InvokeTask                                                 [Mso\src\dispatchQueue\queueService.cpp @ 208]
Microsoft_ReactNative!Mso::TaskDispatcherHandler<...>::Invoke                                       [Mso\src\dispatchQueue\uiScheduler_winrt.cpp @ 208]
CoreMessagingXP!Microsoft::UI::Dispatching::DispatcherQueue::DeferInvokeCallback
CoreMessagingXP!Microsoft::CoreUI::Dispatch::Dispatcher::Callback_DispatchLoop
CoreMessagingXP!Microsoft::CoreUI::Dispatch::UserAdapter::DrainCoreMessagingQueue
...
CoreMessagingXP!Microsoft::UI::Dispatching::DispatcherQueue::RunEventLoop
Microsoft_ReactNative!winrt::Microsoft::ReactNative::implementation::ReactNativeWin32App::Start

Repeated live samples of the same thread also catch it inside DispatcherQueue::TryEnqueueWorker → TryDeferInvoke (the self-re-post) and in ProcessDelayedPropsNodes's vector teardown — i.e. the whole 100%-CPU loop is enqueue → dispatch → fail → enqueue.

Steps to reproduce

1. Fabric composition app with react-native-screens-style native view detachment (or any timing where a view is removed from the registry while its PropsAnimatedNode stays connected).
2. Start an Animated.timing/spring with useNativeDriver: true targeting a transform/opacity on such a view (in our app: a badge pulse animation triggered by a background event while its screen's native views were detached).
3. UI thread spins forever; window stops responding; only recovery is killing the process.

Observed repeatedly in a production app. Full-memory dumps and additional stacks available on request.

Expected behavior

A native animation whose target view cannot be resolved should be retried with backoff/frame pacing and eventually abandoned (or dropped when the node disconnects) — it must not starve the UI thread's message pump.

Suggested fix

In AddDelayedPropsNode/ProcessDelayedPropsNodes:

• schedule the retry on the next batch/frame instead of immediately re-posting to the queue currently being drained, and
• bound the retries (drop the delayed node and log once the view is gone for good, e.g. after N attempts or when the node is disconnected/dropped).