Potential state inconsistency in Transition when used with TransitionGroup

[CircuitCoder]

What is the current behavior?

An (removed) Transition's state may stuck in entering after being removed from TransitionGroup. Unfortunately I've not managed to produce a easy-to-ready MVP. For reproducing, check the end of this issue.

Curiously, it seems that the root cause is that the Transition's componentDidUpdate hook's prevProps is changed without the hook being called, either by someone updating the props object directly, or by React somehow missing a render. The problem is that the in prop of this Transition is managed by TransitionGroup, so each update to the in prop should definitely cause (at least) one componentDidUpdate call.

If we add a log at the start of componentDidUpdate (for convenience, I directly edited the compiled version):

We can see that the Transition is at entering, with prevProps === this.props, but this.props.in === false.

What is the expected behavior?

The state should update correctly.

Reproducing

This issue manifests in https://github.com/jesec/flood, where the loading overlay sometimes fails to hide. In particular, after a successful login or logout, the loading overlay always stays. Related code is at https://github.com/jesec/flood/blob/25fe901c32b99eb68feed5e0abe2071b6420aec2/client/src/javascript/components/AppWrapper.tsx#L77-L83.

I've failed to reproduce this bug in a simplified setting. So this issue may be related to the upper levels of the component tree, and how they manage the tree. So for context, other components that I think might be involved:

• React version: 18.3.1
• Mobx: Using react integration, 7.6.0
• React-router-dom: Router used, but no Route in upper levels. 6.30.1

Help needed

An easy fix is to drop the prevProps === this.props check at https://github.com/reactjs/react-transition-group/blob/master/src/Transition.js#L183, and instead skip the state update if not needed. I can confirm this fixes the issue. But given that this does not solve the root cause, this may be unsatisfactory.

I suspect in order to further track down the bug, more logs are needed. What more logging can I provide in order to help the maintainers fix this?