Context
Two test files use withKnownIssue(isIntermittent: true) to absorb timing-sensitive failures in the withTimeout / withTimeoutAndSignals helpers:
The failure mode is real but platform-bounded: simulator cooperative executors (observed on visionOS, watchOS, and previously wasm32) can starve the polling timeout task's many short Task.sleeps behind the operation task's single long Task.sleep, so the timeout helper returns the value instead of throwing AsyncTimeoutError.
Problem
A blanket withKnownIssue(isIntermittent: true) accepts the failure on every platform. That masks a real regression if the same test starts flaking on a platform where the timeout helper is supposed to be reliable — macOS host, Linux, iOS device, etc.
wasm32 already gets narrower treatment via .enabled(if: !TestPlatform.isWasm32, ...). The other simulator-cooperative-executor platforms are caught only by the broad intermittent gate.
What we want
Scope the intermittent allowance to the platforms that actually flake. Two reasonable shapes:
- Conditional
withKnownIssue: only wrap when on the flaky platform; assert strictly elsewhere.
if TestPlatform.isFlakyTimeoutSimulator {
await withKnownIssue(isIntermittent: true) { ... }
} else {
try await ...
#expect(...)
}
.disabled(if:) for the known-broken set: skip the test on platforms where the helper is unreliable, run it strictly elsewhere. Pairs naturally with the existing TestPlatform.isWasm32 pattern.
Either way: introduce a TestPlatform.isFlakyTimeoutSimulator (or similarly named) helper alongside isWasm32 so call sites stay declarative.
Affected sites
Out of scope
Fixing the underlying scheduling behavior of withTimeout on cooperative-executor platforms. That's a deeper concurrency-runtime topic; this issue is purely about scoping the test gates so a regression on a non-flaky platform fails loudly.
Context
Two test files use
withKnownIssue(isIntermittent: true)to absorb timing-sensitive failures in thewithTimeout/withTimeoutAndSignalshelpers:Examples/MistDemo/Tests/MistDemoTests/Utilities/AsyncHelpers/AsyncHelpersTests+Timeout.swiftExamples/MistDemo/Tests/MistDemoTests/Commands/AuthTokenCommand/AuthTokenCommandTests+Timeout.swift(added in 77715e0 on Resolve #330: interactive MistDemo (web toggle + native app refresh) #332)The failure mode is real but platform-bounded: simulator cooperative executors (observed on visionOS, watchOS, and previously wasm32) can starve the polling timeout task's many short
Task.sleeps behind the operation task's single longTask.sleep, so the timeout helper returns the value instead of throwingAsyncTimeoutError.Problem
A blanket
withKnownIssue(isIntermittent: true)accepts the failure on every platform. That masks a real regression if the same test starts flaking on a platform where the timeout helper is supposed to be reliable — macOS host, Linux, iOS device, etc.wasm32already gets narrower treatment via.enabled(if: !TestPlatform.isWasm32, ...). The other simulator-cooperative-executor platforms are caught only by the broad intermittent gate.What we want
Scope the intermittent allowance to the platforms that actually flake. Two reasonable shapes:
withKnownIssue: only wrap when on the flaky platform; assert strictly elsewhere..disabled(if:)for the known-broken set: skip the test on platforms where the helper is unreliable, run it strictly elsewhere. Pairs naturally with the existingTestPlatform.isWasm32pattern.Either way: introduce a
TestPlatform.isFlakyTimeoutSimulator(or similarly named) helper alongsideisWasm32so call sites stay declarative.Affected sites
AsyncHelpersTests+Timeout.swift— existing intermittent gates onthrowsOnTimeout(~line 58) andreturnsAsyncValue(~line 83); predate this issue.AuthTokenCommandTests+Timeout.swift—timeoutHelperThrowsOnTimeout(~line 46); added in 77715e0 specifically to silence a visionOS-simulator CI flake observed on the Resolve #330: interactive MistDemo (web toggle + native app refresh) #332 run.Out of scope
Fixing the underlying scheduling behavior of
withTimeouton cooperative-executor platforms. That's a deeper concurrency-runtime topic; this issue is purely about scoping the test gates so a regression on a non-flaky platform fails loudly.