Using recording an issue inside of a detached task causes a crash.
Opened this issue · 6 comments
Description
This is something I learned while researching potential ways to address #475. Which, at the time I wrote that issue, I thought would have just resulted in the failure being silently dropped.
The current way of determining what the current reporting tests natively in Swift-Testing is broken when you run an expect inside of a detached task. Technically, you get a failing test result, but it's because the test runner crashed. I haven't yet spelunked enough through the codebase to figure out where that crash is.
This is because Test.current is stored as a task-local value. Which means that when you make an expect inside of a detached task, Swift Testing has lost that context, which means that Test.current is incorrectly (from the semantics of the current running test) as nil.
I don't know the concurrency system well enough to be able to suggest a good solution. The issue is that, because Swift Testing supports task-based parallelization, the value of Test.current strongly depends on the task it's running on. Which makes having a global Test.current like what's in swift-corelibs-xctest the wrong solution.
Expected behavior
No response
Actual behavior
No response
Steps to reproduce
This test should pass. The test runner crashes with a non-zero error instead.
import Testing
@Test func CheckingExpectWithDetachedTasks() async {
await Task.detached {
#expect(Bool(false))
}.value
}
swift-testing version/commit hash
Testing Library Version: 75.7 (arm64e-apple-macos13.0)
Swift & OS version (output of swift --version ; uname -a)
No response
The crash here is a known issue in Xcode 16 Beta, tracked by rdar://122190668. To resolve it, some work will be needed on the Xcode side, but it's also likely some additional action will be needed here in the swift-testing codebase, so I will leave this issue open to track that side of things.
(To clarify: the crash is specific to Xcode 16.)
Having not tried Swift Testing on Xcode 15, is the behavior that it silently drops the issue?
(To clarify: the crash is specific to Xcode 16.)
Right. But that said, other tools (such as VS Code or swift test CLI) may not be handling this situation very clearly in the reporting either, despite not crashing. Because of parallel execution, it's not always obvious which test a particular Issue is associated with. One idea I've had is to keep track of all the currently-running tests and include them as "potentially associated" tests in the reporting, so that at least you can narrow the scope down when troubleshooting.
To clarify more: the crash is specific to Xcode 16, which is the first version of Xcode to include support for Swift Testing. I meant that the crash is a bug in Xcode specifically, and not workflows that involve e.g. Linux or a package dependency on Swift Testing rather than Xcode and the copy of Swift Testing embedded in it.
I hope that makes more sense!
To clarify more: the crash is specific to Xcode 16, which is the first version of Xcode to include support for Swift Testing. I meant that the crash is a bug in Xcode specifically, and workflows that involve e.g. Linux or a package dependency on Swift Testing rather than Xcode and the copy of Swift Testing embedded in it.
I hope that makes more sense!
Oh! I gotcha! Thanks!