WaitForChild should cancel and return nil when Instance it is called from got destroyed

I use WaitForChild a lot and I’m pretty sure a lot of us here do as well

The problem with WaitForChild is that it will hang the thread forever even if that Instance has been destroyed, if it is lo longer useful then we shouldn’t be waiting for it anymore

Most of the issue occurs in Players.PlayerAdded where sometimes the player leaves/disconnects before everything has finished running

I think it’d be better if WaitForChild cancels and returns nil when the Instance it is called from got destroyed so the tread will no longer hang

A lot of our code doesn’t handle WaitForChild returning nil properly or at all
we should be writing better code to handle cases where something doesn’t exist instead of always expecting it to

for clarification i want to keep waiting unless the Parent Instance is destroyed

thank you @colbert2677

1 Like

You should adapt your code for situations such as the one you described.

Although you may have good intentions with this feature request, I feel obliged to reply as this would cause game breaking behavior if it were implemented.

WaitForChild exists for the very reason of waiting for a child to exist. It is incredibly difficult for the engine to know what your use case is when you use WaitForChild, and even if it were to guess that you are waiting for a child that has been destroyed, returning nil would create a bug in code, since it is expected for the function to return the child.


How would WaitForChild know which instance it’s target is if the only thing inputted is a string? I think you should instead make the necessary changes to your code structure instead to avoid your issue.

I don’t think it’s Roblox’s responsibility to address this.

(Collapsed content that comes from a misinterpretation of the thread's wording.)

Forget any compatibility issues this can cause, this feature request fundamentally doesn’t make any sense. WaitForChild would have to know the instance exists to know if it was destroyed to return nil and when WaitForChild knows the instance exists it returns.

Use the timeout argument of WaitForChild if you don’t want your thread to permanently hang and then handle the nil case. You can also use developer community resources like Promise to help you build around this scenario.

Did you mean to ask for WaitForChild to return nil if the instance it was called from is destroyed? That would make more sense and probably help clarify what you’re looking to have done.

local Part = Instance.new("Part")
task.defer(Part.Destroy, Part)
Part:WaitForChild("Wedge") --> Returns nil when Part is destroyed
print("This runs now") --> As of current behaviour, this doesn't

Yes, thanks for making my point clear

and yeah i’m using Promise to wrap around this but being built into WaitForChild would be a lot simpler

The problem with using timeOut parameter is i want to keep waiting unless the Instance is destroyed and it’s no longer useful

clarifying, @MetatableIndex @CriticalDucky my feature request has nothing to do with Child instance I’m talking about the Parent instance being Destroyed

and by implementing this it would encourage us to write code that handle nil cases instead of not having to because it hangs forever

i made this

function instanceUtil.waitForChild(parent: Instance, name: string, timeOut: number)
	local child: Instance? = parent:FindFirstChild(name)
	if child then
		return Promise.resolve(child)

	local promise = Promise.fromEvent(parent.ChildAdded, function(addedChild: Instance)
		return addedChild.Name == name

	local connection
	connection = parent.Destroying:Connect(function()

	if timeOut then

	return promise

1 Like

WaitForChild has a wait time er, id say property, you can use (timeout)


After 10 seconds it will just skip, where then you can do an if it found it, continue, if not, just end it