IPC: handle disconnects and protocol corruption gracefully

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.

[Amaury Levé (Evangelink)]

Summary

Hardens the Microsoft.Testing.Platform IPC layer (named-pipe transport between the test host and its in-process clients) so that a peer disconnect or a corrupt/short header byte no longer takes down the host or client process.

Audit items addressed

Part of the P0+P1 exception-handling audit (items #4–#10, IPC).

Changes

NamedPipeServer.cs

• Replaced ApplicationStateGuard.Unreachable() throws in the header read path with graceful disconnect handling (tolerate short reads, treat mid-header EOF as a normal disconnect).
• Added bounds check currentMessageSize <= 0 → log warning and return cleanly instead of crashing on a corrupt header.
• Wrapped server-side WriteAsync/FlushAsync/WaitForPipeDrain in try/catch (IOException/ObjectDisposedException) → set clientDisconnected and exit the loop after resetting buffers, rather than tearing down the host.

NamedPipeClient.cs

• Symmetric write-side hardening: catches the same IOException/ObjectDisposedException and routes through the existing _environment.Exit(GenericFailure) path used by the read-EOF handler.
• Short-read tolerance on the response header; bounds check currentMessageSize <= 0 → exit on corruption.
• Wrapped response Deserialize in try/catch (excluding OperationCanceledException) so protocol corruption exits cleanly instead of bubbling an undecorated deserialization exception.

Test

• New regression test NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost sends a zero-byte size header via a raw NamedPipeClientStream and asserts the server stays alive instead of throwing ApplicationStateGuard.Unreachable.
• All existing Microsoft.Testing.Platform.UnitTests IPC tests still pass on net9.0.

Notes

• No public API changes.
• Behavior matches the existing GenericFailure exit code used for the read-EOF path on the client side.
• WaitConnectionAsync FailFast is intentionally preserved; only loop-body IO faults get graceful handling.

[Copilot]

Pull request overview

This PR hardens the Microsoft.Testing.Platform named-pipe IPC transport so disconnects and certain protocol-corruption scenarios don’t crash the host/client process (replacing prior “unreachable” paths with graceful exits).

Changes:

• Server: tolerate short/EOF header reads, reject non-positive message sizes, and handle write-side disconnects without FailFast.
• Client: add write-side disconnect handling, tolerate short response headers, and treat response deserialization failures as a generic IPC failure exit.
• Tests: add a regression test to ensure an invalid (0) message-size header doesn’t crash the host.

Show a summary per file

File	Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs	Adds regression coverage for invalid message-size header handling on the server.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs	Makes the server loop tolerant to mid-header EOF/short reads and write-side disconnects; logs and exits cleanly on certain corrupt headers.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeClient.cs	Adds write-side disconnect handling, short-read header handling, and exits cleanly on corruption/deserialization errors.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Amaury Levé (Evangelink)]

Test Coverage Gaps

The PR introduces 8 new error paths but only tests 1 (server-side zero message size). Missing test scenarios:

Client-side (4 untested paths):

1. Write-side IOException: Server closes pipe during WriteAsync → verify _environment.Exit(GenericFailure) called
2. Mid-header disconnect: Server sends 2 bytes then closes → verify _environment.Exit and IOException thrown
3. Negative message size: Server sends -1 header → verify _environment.Exit and InvalidOperationException thrown
4. Deserialization failure: Server sends corrupted payload → verify _environment.Exit called

Server-side (3 untested paths):

5. Mid-header disconnect: Client sends 2 bytes then closes → verify graceful loop exit
6. Negative message size: Client sends -1 header → verify warning logged and loop exits (existing test only covers zero, not negative)
7. Byte-count overflow: Client declares N bytes but writes >N bytes → verify warning logged and loop exits
8. Write-side IOException: Client disconnects during server reply → verify graceful loop exit

All 8 scenarios are concrete failing interleavings that the new code explicitly handles. Recommend adding these tests to prevent regressions.

Generated by Expert Code Review (on open) for issue #8602 · ● 4M · ◷

[Youssef Fahmy (Youssef1313)]

This is adding a lot of additional code. Is there a concrete bug that makes it worth adding this?

[Amaury Levé (Evangelink)]

(Reading this as a question rather than a request to revert — happy to do either.)

No specific user-visible repro for the write-side hardening, but it's there to keep the client symmetric with the existing read-EOF path right below it: today, if the server disconnects mid-write the client surfaces a raw IOException/ObjectDisposedException to whoever called RequestReplyAsync (e.g. the test host orchestration code) instead of the deterministic _environment.Exit(GenericFailure) we already use for read-EOF. Two cases this matters in practice:

1. dotnet test orchestration tears down the test host process mid-RPC — caller gets a raw IO exception instead of the documented exit code.
2. The MTP host crashes/FailFasts on its end while the client is flushing — same thing.

The concrete server-side bug fixed in this PR (the one with the regression test) is the ApplicationStateGuard.Unreachable() -> FailFast crash on a corrupt/short header byte. The client write-side changes are essentially: 3 lines of catch (Exception ex) when (ex is IOException or ObjectDisposedException) doing what the read-EOF block 30 lines above already does.

If you'd rather I scope this PR down to just the server-side crash + the matching read-side tightening and pull the write-side symmetry into a separate PR (or just drop it), happy to do that — let me know.

[Amaury Levé (Evangelink)]

🔍 Build Failure Analysis

Summary — The build failed due to a code style violation: a using statement can be simplified to a using declaration.

Root cause: IDE0063 style rule violation

The newly added test method NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost uses a traditional using statement with braces on line 261:

using(varraw=newSystem.IO.Pipes.NamedPipeClientStream(...)){// ...}

The project enforces [IDE0063]((learn.microsoft.com/redacted) as an error, which requires the simpler using declaration pattern:

usingvarraw=newSystem.IO.Pipes.NamedPipeClientStream(...);// ...

This single style violation is reported for each target framework the project builds (net8.0 and net9.0), resulting in multiple error instances from the same root cause.

Affected files / errors

• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net8.0)
• test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs:261 — IDE0063: 'using' statement can be simplified (net9.0)

Proposed fix

Convert the traditional using statement to a using declaration and adjust the code block accordingly:

 Task waitConnection = server.WaitConnectionAsync(_testContext.CancellationToken);
- using (var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous))- {- await raw.ConnectAsync(_testContext.CancellationToken);- await waitConnection;+ using var raw = new System.IO.Pipes.NamedPipeClientStream(".", pipeNameDescription.Name, System.IO.Pipes.PipeDirection.InOut, System.IO.Pipes.PipeOptions.Asynchronous);+ await raw.ConnectAsync(_testContext.CancellationToken);+ await waitConnection;- // Write a zero-length message size header (invalid per protocol).- byte[] invalidHeader = BitConverter.GetBytes(0);- await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);- await raw.FlushAsync(_testContext.CancellationToken);- }+ // Write a zero-length message size header (invalid per protocol).+ byte[] invalidHeader = BitConverter.GetBytes(0);+ await raw.WriteAsync(invalidHeader, 0, invalidHeader.Length, _testContext.CancellationToken);+ await raw.FlushAsync(_testContext.CancellationToken);

---

Build overview

Configuration: Debug
Exit code: 1 (failure)
Error count: 2 (4 instances across target frameworks)
Warning count: 0

Failed project:

• Microsoft.Testing.Platform.UnitTests.csproj (net8.0, net9.0)

All MSBuild errors (2)

Code	Project	File:Line	Message
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net8.0)
IDE0063	Microsoft.Testing.Platform.UnitTests	IPCTests.cs:261	'using' statement can be simplified (net9.0)

---

_{🤖 Generated by the Build Failure Analysis workflow · commit 60797b2}

Generated by Build Failure Analysis for issue #8602 · ● 2.2M · ◷

[Amaury Levé (Evangelink)]

Generated by Build Failure Analysis for issue #8602 · ● 2.2M

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Amaury Levé (Evangelink)]

Thanks for the careful review — you're right on both points and I just pushed a commit that addresses them.

What I changed back (your feedback)

• NamedPipeServer.cs: restored throw ApplicationStateGuard.Unreachable() for both currentReadBytes < sizeof(int) and missingBytesToReadOfWholeMessage < 0. Also dropped the added currentMessageSize < sizeof(int)LogWarning path. You're right that LogWarning is the wrong severity for an unexpected-state condition the user can't act on, and replacing a documented invariant with handling logic without evidence the condition is reachable is regressing the design that was carefully worked out with Marco.
• NamedPipeClient.cs: same reasoning — dropped the symmetric short-read loop, the size bounds check, the overshoot check, and the try/catch around Deserialize that I had mirrored. None of them were driven by evidence and they were adding untested error paths.
• Dropped the NamedPipeServer_InvalidMessageSizeHeader_DoesNotCrashHost regression test (it was only validating the behavior we just reverted).

What I kept

Only the parts where the exceptions are caused by an externally observable condition (the peer process crashing/exiting mid-write), not by an internal invariant:

• NamedPipeServer.cs: try/catch (IOException or ObjectDisposedException) around the reply WriteAsync/FlushAsync/WaitForPipeDrain so a client that disconnects between request and reply doesn't FailFast the host.
• NamedPipeClient.cs: symmetric try/catch on the request write side that routes through the same _environment.Exit(GenericFailure) path the existing read-EOF handler uses.

These match the existing read-EOF handling (currentReadBytes == 0 -> graceful return / Exit(GenericFailure)) and don't touch any invariant.

Expert reviewer

I also updated .github/agents/expert-reviewer.agent.md so the same pattern gets flagged in future reviews — added rules to Algorithmic Correctness and Defensive Coding at Boundaries:

• Don't weaken ApplicationStateGuard.Unreachable() / Debug.Assert / invariant throws into ""graceful"" handling without a concrete repro.
• An internal-bug condition is LogError + abort, never LogWarning (which is user-actionable severity).
• Defensive coding belongs at trust boundaries, not on internal invariants between trusted in-process components.

All 965 Microsoft.Testing.Platform.UnitTests still pass on net9.0.