Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#16,309 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
cpp, react-native
Área
desktop-dev, frontend

Línea de trabajo

Comienza en vnext/Microsoft.ReactNative/Modules/Animated/PropsAnimatedNode.cpp y NativeAnimatedNodeManager.cpp, siguiendo StartAnimations(), AddDelayedPropsNode() y ProcessDelayedPropsNodes(). Reproduce el problema con una vista Fabric ausente y verifica que los reintentos cedan el control al message pump, se detengan tras una condición acotada y ya no dejen el UI thread bloqueado permanentemente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Needs: Triage :mag:

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).
Lenguaje dominante
C++
Estrellas
17.4k
Forks
1.2k
Merge medio
2 d 17 h
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/react-native-windows

Todos los issues de microsoft/react-native-windows

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.