Fix Common.Interop.UnitTests.TestSend infinite hang on CI#47123
Merged
LegendaryBlair merged 1 commit intomicrosoft:mainfrom Apr 21, 2026
Merged
Fix Common.Interop.UnitTests.TestSend infinite hang on CI#47123LegendaryBlair merged 1 commit intomicrosoft:mainfrom
LegendaryBlair merged 1 commit intomicrosoft:mainfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a CI hang in Common.Interop.UnitTests.TestSend by eliminating cross-run named pipe collisions and replacing an unbounded wait with a bounded timeout, so broken pipe handshakes fail quickly instead of timing out the job.
Changes:
- Generate unique machine-global named pipe names per test run using
Environment.ProcessId+Guid. - Replace
reset.WaitOne()withAssert.IsTrue(reset.WaitOne(timeout))and a diagnostic timeout message.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
The test used machine-global pipe names (\\.\pipe\serverside, \\.\pipe\clientside) and an unbounded reset.WaitOne(). On CI this combination could hang the x64 leg for the full 80-minute job timeout when two runs collided on the same agent or the pipe handshake raced. - Suffix pipe names with Environment.ProcessId + Guid so every run gets a unique pair, eliminating cross-run collisions on shared agents. - Bound WaitOne to 30s with an assertive failure message so a genuine handshake failure fails the test quickly with diagnostics instead of starving the CI job. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
yeelam-gordon
force-pushed
the
fix/interop-test-hang
branch
from
f632529 to
c893837
Compare
LegendaryBlair
approved these changes
Apr 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fixes an infinite hang in Common.Interop.UnitTests.TestSend that caused the x64 CI job to time out at 80 minutes on retried runs (originally observed on #47106, but the race is latent in any run that shares a CI agent with a previous run).
Root cause
The test used two machine-global named pipes (\.\pipe\serverside and \.\pipe\clientside) as fixed constants, and waited for the pipe callback with an unbounded
eset.WaitOne().
If a prior test run on the same CI agent left a pipe handle alive (e.g. after a job cancellation or a flaky cleanup), the next run's TwoWayPipeMessageIPCManaged handshake would silently never complete, and
WaitOne()would block until the pipeline's job-level timeout (~80 minutes) killed the agent.Fix
Two small, orthogonal changes in
InteropTests.cs:Environment.ProcessId+ a freshGuid, so runs on the same agent can never collide.reset.WaitOne(TimeSpan.FromSeconds(30))wrapped inAssert.IsTruewith a diagnostic message identifying the pipes. A broken handshake now fails the test in 30 s with a clear error, instead of hanging the CI job.The inner
Assert.AreEqual(testString, msg)— the actual correctness check — is unchanged. On the happy path the callback fires in milliseconds and the test behaves identically to before.Verification
Built and ran locally with VS2026 MSBuild (x64 Release):
TestSendpasses in ~139 ms.Follow-up (not in this PR)
TwoWayPipeMessageIPC.cppstill relies on aThread.Sleep(100)race workaround (comment in the test) for server-ready timing. A proper handshake there would let us drop the sleep; out of scope here.