[7.0] Fix reporting of an async IO timeout error on Windows (SerialPort)
#81745
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SerialPort) #81744SerialPortIO operation times out, it reports the timeout in the IO completion with anNTSTATUSvalue ofWAIT_TIMEOUT(258)GetQueuedCompletionStatusEx, theNTSTATUSvalue was being checked againstSTATUS_SUCCESSto determine success, so theWAIT_TIMEOUTwas reported as an error. This leads to a different exception being thrown, compared to before whenGetQueuedCompletionStatuswas used.NT_SUCCESSmacro, which treats theWAIT_TIMEOUTvalue as a success, which is similar to whatGetQueuedCompletionStatusdoesSystem.IO.Portstests, though they are currently disabled due to instabilities. I have verified locally that the relevant failures are fixed and that there are no new failures in those tests.Port of fix for #80079
Customer Impact
A
SerialPortIO operation that times out raises anIOExceptioninstead of the documentedTimeoutException. Some customers have reported the issue and that it has broken several apps usingSerialPorton Windows. There is a runtime config option that can be configured to revert the change in behavior, which serves as a workaround. Another workaround is to catch theIOExceptionand check the error code.Regression?
Yes, from 6.0
Testing
Verified with the repro that the behavior is the same as before
Risk
Low. .NET 6 uses
GetQueuedCompletionStatus, and after the change the behavior is closer to whatGetQueuedCompletionStatusdoes.