is_in_tree returns false even though node is in tree

[Watersilver]

Tested versions

• Reproducible in: v4.4.1.stable.official [49a5bc7], v4.2.stable.official [46dc277]

System information

Godot v4.4.1.stable - Windows 10 (build 19045) - Multi-window, 2 monitors - OpenGL 3 (Compatibility) - NVIDIA GeForce RTX 2060 (NVIDIA; 32.0.15.6094) - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 threads)

Issue description

I have a level manager that packs its children (rooms) as scenes so they can be instantiated when appropriate. Here's a simplified version of how it does that:

## This node packs all its children as scenes

extends Node2D
class_name Packer

var packed: Array[PackedScene] = []

func _ready() -> void:
	# Iterate children to pack them as scenes
	for child in get_children():
		
		# set the owner of every descendant of child to child so it will get packed too
		for subchild in child.find_children("*"):
			subchild.owner = child
		
		# For some reason packing works even when commenting out the following line
		remove_child(child) # But in my actual project it doesn't
		
		# Store in packed scenes array
		var p := PackedScene.new()
		p.pack(child)
		packed.push_back(p)
		
		
		child.queue_free()

Under certain conditions some children nodes of the scene that was packed by the level manager exist inside the scene tree (I checked the remote scene tree) even though their is_in_tree method returns false. I also can't interact with them properly. For example if I change their position, nothing happens visually. At that point if I remove_child on the buggy node and then re-add it, it seems to get duplicated even though the remote scene tree only shows one instance of it. This can be seen when the buggy node is a sprite because there are two of them on screen and one of them in the remote scene tree.

The conditions seem to be:

• The buggy node must be part of a different scene, not the level manager or packer or whatever scene packs it
• It must not be the root node of that different scene
• The different scene itself must not be a child of the node that does the packing, it must be the child of the child (or presumably any descendant)
• The buggy node must have a unique name and be accessed in its scene by its unique name. I found this out after a lot of testing

So the node hierarchy for the packer should be something like:
Packer
|Child
||Subchild(scene that bugs out)

And the node hierarchy for the buggy scene should be something like:
Root
|%UniqueNamedChild

---

I've discovered a "fix" for the packing code that avoids the issue. When setting ownership for the subchildren (yeah I know it's a weird name, couldn't think of anything better) I avoid changing owner for the ones that are children that belong to a different scene. They still get packed for some reason, even though the docs say that the sub-nodes (ah that's where I got the subchildren idea...) are only packed when owned. I assume that's because the child scene is itself packed recursively and it owns its children.

It's also possible to avoid the issue if you don't use unique names.

However the issue with the duplication and the node that appears on screen but not the scene tree has gotten me a bit anxious about memory leaks and I'm not sure if either of these workarounds are safe. If anyone takes a look at the source code please let me know if they are safe ways to circumvent the issue.

Steps to reproduce

The MRP has only three scenes.

A Packer scene that contains the code I linked above along with the "fix" I described (can be toggled on and off in the editor).
A SubchildScene (ugh) that simply prints if its Sprite2D child is_inside_tree and also has a in editor toggle to remove and re-add causing the duplication if it's bugged.
A main scene that runs when you run the project. It has two buttons to load the two scenes the packer has packed. The fist one isn't bugged in any way that I've seen, as they're nodes belonging to the packer scene, but the second is bugged.

If you use the toggles you can see everything I described above except the non unique name workaround so if you go to the SubchildScene and replace the % with a $ you can see that too.

Minimal reproduction project (MRP)

not-inside-tree.zip

[Rindbee]

You broke the child scene (SubchildScene) but didn't completely localize it (didn't clear SubchildScene's scene_file_path), so when instantiated, it should instantiate 2 Sprite2Ds at the same path with the same name, one for the new scene (owner is child) and one for the child scene (original owner). That is, the scene you package contains the original sub-scene.

This should throw an error during adding child while instantiating, but since _add_child_nocheck() is used when instantiating the scene, no error was thrown during instantiation. Adding fails silently.

So, this is not a bug. Normally, two nodes are not allowed to exist on a path. But you change the owner, making this possible. But perhaps a warning should be given.

[Watersilver]

Good to hear. I didn't know about the scene_file_path property. Seems like a better way to detect if a node is a scene root that what I'm using.

I agree that at least a warning should be given. Packing scenes can be a way to save game progress and it should be easy for users to do it at runtime. Giving them feedback to do it properly is on the right track I think.

I still don't understand why not using unique names seemingly circumvents the issue and why the duplicated node doesn't appear on the remote scene tree.

[Rindbee]

.
Control
Control/MarginContainer
Control/MarginContainer/HBoxContainer
Control/MarginContainer/HBoxContainer/LoadChild1
Control/MarginContainer/HBoxContainer/LoadChild2
Packer
Node2D2                                             # new scene
Node2D2/SubchildScene                               # SubchildScene
Node2D2/SubchildScene/Sprite2D                      # create by instantiating SubchildScene, will be replaced by the one below.  the owner is Node2D2/SubchildScene
Node2D2/SubchildScene/Sprite2D                      # create by instantiating new scene, the owner is Node2D2

When instantiating the new scene, SubchildScene will be instantiated first. Due to the following code, the same path nodes will be replaced. A check should be added here as it may cause leaks.

godot/scene/main/node.cpp

Line 1642 in e1b4101

data.children.insert(p_name, p_child);

Nodes with unique name enabled will be cached by its owner's owned_unique_nodes. The above two nodes are cached by Node2D2/SubchildScene and Node2D2 respectively.

godot/scene/main/node.cpp

Line 2179 in e1b4101

data.owner->data.owned_unique_nodes[key] = this;

godot/scene/main/node.cpp

Lines 1873 to 1877 in e1b4101

	} else if (name.is_node_unique_name()) {
	Node **unique = current->data.owned_unique_nodes.getptr(name);
	if (!unique && current->data.owner) {
	unique = current->data.owner->data.owned_unique_nodes.getptr(name);
	}

When searching by path, since the script is attached to Node2D2/SubchildScene, the Node2D2/SubchildScene is searched first. If not found, the owner (Node2D2) of the Node2D2/SubchildScene is searched (it is skipped here). In simple terms, there are two nodes with the same unique name in different scenes. Searching from the subscene root will find the one in the subscene first. The special point here is that these two nodes share the same path. In fact, they are not the same path, but each occupies a cache.

[Watersilver]

Thank you, this explains everything. I guess I should leave the issue open though, since you found a place with potential leaks,