Swift version
main
Platform
Windows
Editor
No response
Description
LocalSwiftTests.testSourceKitdTimeout fails intermittently on Windows CI, always on the same assertion with the same message:
C:\…\sourcekit-lsp\Tests\SourceKitLSPTests\LocalSwiftTests.swift:1488: error: LocalSwiftTests.testSourceKitdTimeout : XCTAssertEqual failed: ("Optional([])") is not equal to ("Optional(["Cannot convert value of type 'Int' to specified type 'String'"])")
Three occurrences so far, two of them on scheduled builds of main, all identical down to the duration:
The failure is the second assertion in the test, not the first. The test sets options.sourcekitdRequestTimeout = 3 (LocalSwiftTests.swift:1438), sends a diagnostics request that is expected to time out and return no diagnostics — that assertion at line 1473 passes — then edits the file and expects the follow-up request to return a real diagnostic. On these runs the follow-up request times out too, so the test gets [] instead of the Cannot convert value of type 'Int' to specified type 'String' diagnostic.
The 3 second value is already acknowledged as marginal on this platform. The comment above it reads:
// This is how long we wait until implicitly cancelling the first diagnostics request.
// It needs to be long enough so we can compute diagnostics for the second requests.
// 1s is not sufficient on Windows for that.
options.sourcekitdRequestTimeout = 3 /* seconds */
Simply raising the number isn't obviously right, because the value is load-bearing in both directions: it has to be short enough that the first request is actually cancelled (that's what the test is verifying) and long enough that the second one completes. On a machine where a request can occasionally take many seconds, no single constant satisfies both. Decoupling the two — for example cancelling the first request explicitly rather than relying on the timeout, so the timeout only has to bound the second — would remove the conflict.
This is likely aggravated by the broader Windows instability in #2766, where requests that normally complete in milliseconds occasionally stall for the full timeout. But it is worth tracking separately: the failure here is reproducible in shape, always at line 1488, always at ~9 seconds, whereas the #2766 failures vary run to run and are dominated by index-store timeouts, of which there are none in these three builds.
Logging
Full Jenkins console logs attached, gzipped (raw they are ~28 MB each, over GitHub's attachment limit).
Useful greps:
LocalSwiftTests.swift:1488: error # the failing assertion
testSourceKitdTimeout # the test's captured output block
Updating index store failed: Timed out # absent in all three, unlike the #2766 failures
sourcekit-lsp-PR-windows-4268.txt.gz
swift-PR-windows-status-1113.txt.gz
swift-PR-windows-status-1126.txt.gz
Swift version
main
Platform
Windows
Editor
No response
Description
LocalSwiftTests.testSourceKitdTimeoutfails intermittently on Windows CI, always on the same assertion with the same message:Three occurrences so far, two of them on scheduled builds of
main, all identical down to the duration:The failure is the second assertion in the test, not the first. The test sets
options.sourcekitdRequestTimeout = 3(LocalSwiftTests.swift:1438), sends a diagnostics request that is expected to time out and return no diagnostics — that assertion at line 1473 passes — then edits the file and expects the follow-up request to return a real diagnostic. On these runs the follow-up request times out too, so the test gets[]instead of theCannot convert value of type 'Int' to specified type 'String'diagnostic.The 3 second value is already acknowledged as marginal on this platform. The comment above it reads:
Simply raising the number isn't obviously right, because the value is load-bearing in both directions: it has to be short enough that the first request is actually cancelled (that's what the test is verifying) and long enough that the second one completes. On a machine where a request can occasionally take many seconds, no single constant satisfies both. Decoupling the two — for example cancelling the first request explicitly rather than relying on the timeout, so the timeout only has to bound the second — would remove the conflict.
This is likely aggravated by the broader Windows instability in #2766, where requests that normally complete in milliseconds occasionally stall for the full timeout. But it is worth tracking separately: the failure here is reproducible in shape, always at line 1488, always at ~9 seconds, whereas the #2766 failures vary run to run and are dominated by index-store timeouts, of which there are none in these three builds.
Logging
Full Jenkins console logs attached, gzipped (raw they are ~28 MB each, over GitHub's attachment limit).
swift-PR-windows-status-1113.txt.gzswift-PR-windows-status-1126.txt.gzsourcekit-lsp-PR-windows-4268.txt.gzUseful greps:
sourcekit-lsp-PR-windows-4268.txt.gz
swift-PR-windows-status-1113.txt.gz
swift-PR-windows-status-1126.txt.gz