[MP] Partially revert cache cleanup, track paths as fallback #94984
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cleaning up remote NodePath cache is not trivial since the visibility API allows for certain nodes to be despawned (and re-spawned) on some peers while being retained in the authority.
This means that from the server point of view, the node has not changed, and the path simplification protocol won't be run again after respawning.
While we can track this information for synchronizers via the replication API, we can't easily track this information for potential child nodes that use RPCs (I'm convinced it is doable, but we need to track the whole dependency tree which would require some more complex refactoring).
This commit partially reverts some of the cache cleanup logic to always retain remote IDs, and adds a NodePath lookup fallback when the ObjectID is invalid.
Fixes #90908 (regression from #87190). For 4.2, we might instead want to playing safe card of just reverting #87190 (I greatly underestimated the side effects it could have).