BindToClose 100% Infinite Yield

[ianchua1 (iii)]

Same here, this problem is back and it slows down my progress making games

[sunkiqxed]

I am currently having the same issue. It really wastes development time.

[mario118118]

Can confirm this is also happening for me.

[Automationeer (Eleanor)]

The Code

local DataStoreService = game:GetService("DataStoreService")
local DataStore = DataStoreService:GetDataStore("Datastore")

print(1, DataStore:GetAsync("Key1"))
print(2, DataStore:GetAsync("Key2"))
print(3, DataStore:GetAsync("Key3"))

game:BindToClose(function()
	DataStore:SetAsync("Key1", os.time())
	DataStore:SetAsync("Key2", os.time())
	DataStore:SetAsync("Key3", os.time())
end)

Studio Test

After running the code, it returned that all keys were nil

When I pressed Stop, my studio froze and I got the infamous error after a bit of waiting

13:59:59.373 - Not running script because past shutdown deadline (x97)

The next time I joined, it had only saved 1

1 1574603969
2
3

Live Server test

I ran the test on the live server and can (thankfully) conclude that this is only an issue in studio.

---

Can we please get someone to look into this?
cc @CycloneUprising

[Wasteds]

It’s really annoying and slowing work down so much! Please fix this asap

(It happened last week for about couple of hours then got fixed in morning, and now it’s back from past day)

[CycloneUprising]

I have a fix. Unfortunately it may take longer than normal to get into production because of the Thanksgiving holiday.

Very sorry for the inconvenience, and thanks for your patience.

[Quenty]

Not all heroes wear capes. Thank you!

[laughablehaha]

I’m glad this is being fixed. I cooked myself dinner and took a nap before studio unfroze from this!

[Ethanthegrand14 (Ethanthegrand)]

Glad you do, this bug has been very annoying when i test something and then i stop, and it ends up taking like 10 seconds just to stop.

[EncodedLua (Juniper)]

DataStore2 probably uses yielding in the BindToClose code, so it’s not a problem with DS2. Roblox is fixing the issue now.

[TinpotOps]

Don’t know if anyone’s mentioned this yet, but the stall also happens with HttpService requests. Sometimes the stall alleviates itself without error, sometimes it doesn’t. Not entirely reproducible for the case of HttpService. Was wondering if anyone else had this issue and it looks like nearly everyone does, just with a different service.

[mjones_dewberry]

Mine is also hanging now when the Datastore request is in PlayerRemoving.

[Wingz_Avard (Avard)]

HttpService requests are yielding functions. As this bug happens when anything yields in BindToClose, calling Http Async functions within BindToClose when this issue is persistent will result in BindToClose yielding until it times out.

[DataBrain (Amber)]

The time it took to resolve this issue both times it happened is kind of concerning, given how many user reports there were and that it requires developers to manually work around it at the expense of potential data loss related bugs. Are there any test cases set up to prevent this from happening again?

[Automationeer (Eleanor)]

Hey @CycloneUprising, has the fix been pushed yet? I’m still receiving this error, and have to resort to using Test Server which is really slow and cumbersome for my work flow.

 15:26:08.427 - Not running script because past shutdown deadline (x117)

[AlgyLacey (Algy)]

Yeah, this issue is still happening for me too.

[Jaklic]

I think it’s been fixed. At least for me… I’m still waiting for the official patch info.

[nsgriff (griffted)]

This should be fixed. Please let us know if you have ongoing issues.

[acreol]

It’s not fixed for coroutines:

game:BindToClose(function()
	local t=coroutine.running()
	delay(1,function()
		coroutine.resume(t)
	end)
	coroutine.yield()
end)

There are many more coroutine bugs too:

ModuleScripts that yield with coroutine.yield() will break parent thread

If this is a server script: print'before' require(script.ModuleScript) print'after' and it has this ModuleScript as its child: local t=coroutine.running() delay(1,function() coroutine.resume(t) end) print'yielding' coroutine.yield() print'resumed' return nil Then the output will be before yielding resumed The ‘after’ is never printed, while it should be. If anyone happens to know a workaround, please let me know.

Coroutine.resume() bug while used in RemoteFunction & BindableFunction

I was excited to use the changed coroutine.yield on my project while I came across this coroutine issue while using it on RemoteFunction(OnServerInvoke). ServerScript: print("Server>> Initialized"); local remote = game.ReplicatedStorage.Request; remote.OnServerInvoke = function(player) local currentThread = coroutine.running(); print("Server>> Server invoked, Thread:",currentThread); coroutine.wrap(function() wait(1); coroutine.resume(currentThread, "Hello"); end)(); print("Server>…

Pcall/ypcall don't work with coroutine resume

This happens all the time in studio and in game print'-' pcall(function() local t=coroutine.running() delay(1,function() coroutine.resume(t) end) print'yielding' coroutine.yield() print'resumed' end) print'a'--never outputted, but should be Replacing pcall with ypcall doesn’t work either But the code runs with no problems if coroutines are replaced with wait() or BindableEvents I think this problem is similar to a lot of other ones with coroutines also

[CycloneUprising]

The fix I mentioned in earlier post is now live.