YieldFunctions will never resolve in PlayerRemoving

Bug Reports Studio Bugs
#1

Reproduction Steps
(This is assuming you do not have BindToClose connected since this is an issue with the event itself)

Write this code inside a script, you will notice the wait function never resumes:

Players.PlayerRemoving:Connect(function()
  wait(2)
  print("hi!")
end)

Expected Behavior
Studio should wait until all PlayerRemoving threads report as dead not yielding, and as such, the code above should print Hi!

Actual Behavior
Because Studio tracks these threads until they yield, not die, it results in the code above never working. This also affects breakpoints since they yield the thread.

Studio will stop a session once all threads are considered yielding. The behaviour here should be changed so that threads under PlayerRemoving should run until dead

Workaround
Connect BindToClose to a function and make it wait the maximum exhaustion time of 30 seconds (or using some hacky implementation that holds the game until all PlayerRemoving threads report as dead, this should be default behaviour)

Issue Area: Studio
Issue Type: Performance
Impact: High
Frequency: Constantly

2 Likes
#2

This behaviour may also extend to LocalScripts in the client.

#3

Do you have the source as to why this should be the case? (As in, Roblox said it should happen) I can understand it would be waiting until it’s dead or started yielding, but not after that.

Otherwise this kind of fits more into a feature request in my understanding.

#4

Debugging and DataStores. I’ve seen a few posts that address an issue with user data not saving, and they all seem to revolve around this base issue.

There has also been a post about how its impossible to use debugging tools on PlayerRemoving for this very reason.

As to why I’ve marked it as a bug, you are correct in that this is intentional behaviour, however it makes this function frustrating to work with in Studio if it ever has to yield for any period of time

1 Like
#5

The function doesn’t yield, it’s the server instance being terminated right after you press “Stop” button in Studio. It shouldn’t be considered as a bug.

#6

BindToClose is the intended way to handle this.

It’s really a “where do you draw the line” problem. Yes, we could make PlayerRemoving have the same infrastructure that BindToClose does, but what about ChildRemoved, what about AncestryChanged? Those also end up firing on players leaving, for instances under the player in addition to the player too. What if you have custom extra signals that you fire and listen on in your PlayerRemoving function?

The clearest line to draw is that BindToClose is the function you use for anything that you want to delay game close while you do cleanup.

3 Likes
#7

Hmm, bit of an interesting implementation but makes sense if you want to draw the line there.

Completely went over my head that other signals are going to fire if you disconnect the client.

#8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.