Any updates on error coming from this code? (mentioned in the post too)
local Thread = task.spawn(function()
workspace.ChildAdded:Wait()
end)
task.cancel(Thread)
Instance.new("Part", workspace)
Any updates on error coming from this code? (mentioned in the post too)
local Thread = task.spawn(function()
workspace.ChildAdded:Wait()
end)
task.cancel(Thread)
Instance.new("Part", workspace)
Fix for Wait/WaitForChild is implemented internally and should come in a future update (will be mentioned in the Release Notes 592+).
Threads cancelled while waiting on Wait/WaitForChild will no longer report an error.
Will they still stay in memory after cancelling them? Like keeping the coroutine in memory still until an object gets added or when the event gets triggered?
Or is just the error being removed? (Anyways I like that this was changed)
When task.cancel
is called, only the reference to the thread object remains, parameters and target function reference/upvalues are cleared immediately.
Wait completion handler is still registered, but when it’s triggered, it will no longer attempt to resume the target that was cancelled.
Your suggestion for task cancellation callback is still a good idea to handle cases where connections have to be disconnected. Can’t do that automatically - functions passed to Connect are not owned by the thread and in some cases might be intended to remain connected.
But I have no timeline for when such feature will be added.
I’m still encountering this error with more niche yielding methods like InvokeServer().
Currently having a similar issue with hanging HTTP requests (run the code a few times)
local HttpService = game:GetService("HttpService")
HttpService.HttpEnabled = true
local function Request(timeout)
HttpService:RequestAsync({ Url = "https://httpstat.us/504?sleep=" .. timeout * 1000 })
end
local function Timeout(timeout)
local reqThread = task.spawn(Request, timeout)
task.delay(timeout - 1, function()
task.cancel(reqThread)
print("Cancelled")
end)
end
Timeout(2)
It seems to work fine with GetAsync
but, from what I’ve observed, this dead coroutine
issue affects almost any method that yields & tries to resume in a thread that has been cancelled after the method yielded.
Is there any chance that this could be patched within the task & coroutine
libraries (or internals of them), or maybe in the way that yielding is done? As it seems to be the root cause of the majority of these errors.
In other words, RequestAsync
isn’t at fault here, imo.