Fix infinite loop in DeflateStream/GZipStream BeginWrite with .NET Standard 2.0 derived classes by Copilot · Pull Request #124143 · dotnet/runtime

Copilot · 2026-02-08T10:41:32Z

Description

BeginWrite in DeflateStream and GZipStream causes infinite recursion when invoked on derived classes compiled against .NET Standard 2.0 and used in .NET Core 3.1+.

Root cause: In .NET Standard 2.0, these classes don't override WriteAsync(byte[], int, int, CancellationToken). When a derived class calls base.WriteAsync, it hits Stream.WriteAsync which uses the Begin/End pattern, calling BeginWrite. The .NET Core 3.1+ implementation of BeginWrite then calls WriteAsync, creating the loop:

Stream.WriteAsync(ROM) → Stream.WriteAsync(byte[]) → BeginWrite → WriteAsync(byte[]) → (loop)

Fix: Changed BeginWrite to call WriteAsyncMemory directly, bypassing the WriteAsync indirection that creates the cycle.

Changes

DeflateStream.cs:

-public override IAsyncResult BeginWrite(...) =>
-    TaskToAsyncResult.Begin(WriteAsync(buffer, offset, count, CancellationToken.None), ...);
+public override IAsyncResult BeginWrite(...)
+{
+    ValidateBufferArguments(buffer, offset, count);
+    return TaskToAsyncResult.Begin(WriteAsyncMemory(new ReadOnlyMemory<byte>(buffer, offset, count), CancellationToken.None).AsTask(), ...);
+}

GZipStream.cs: Same pattern, delegates to _deflateStream.WriteAsyncMemory.

Tests: Added regression tests simulating .NET Standard 2.0 derived streams with byte[] WriteAsync override. Tests verify completion within 5 seconds (previously hung indefinitely).

Type of change

Bug fix (non-breaking change which fixes an issue)

Original prompt

This section details on the original issue you should resolve

<issue_title>DeflateStream as a base class causes infinite loop in async scenario.</issue_title>
<issue_description>DeflateStream in .net standard 2.0 does not have the method WriteAsync(...). If a class derives from DeflateStream(.net standard 2.0) and used in .net core 3.1, then the WriteAsync(..) goes to infinite loop because:

-Since DeflateStream(.net standard 2.0) does not have WriteAsync(..), the Stream.WriteAsync is used.
-Stream.WriteAsync(..) internally calls BeginWrite(..)
-BeginWrite(..) method of DeflateStream(.net core 3.1) internally calls WriteAsync(..)

//implement this in a .net standard 2.0 assembly
//all properties and methods simply call corresponding property or method in the base
public class MyStream : DeflateStream
{
    public override Task WriteAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
    {
        return base.WriteAsync(buffer, offset, count, cancellationToken);
    }

    //rest of code
}

//reference the assembly above from a .net core 3.1 project.

MyStream stream = new MyStream(new MemoryStream(), CompressionMode.Compress);

//the line below goes in an infinite loop
stream.WriteAsync(new byte[]{1,2}, 0, 2, new CancellationToken());

```</issue_description>

<agent_instructions>Make sure this hasn't already been fixed in .NET 10 (or earlier).</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
<comment_new><author>@</author><body>
Tagging subscribers to this area: @dotnet/area-system-io
See info in [area-owners.md](https://github.com/dotnet/runtime/blob/main/docs/area-owners.md) if you want to be subscribed.
<details>
<summary>Issue Details</summary>
<hr />

DeflateStream in .net standard 2.0 does not have the method WriteAsync<T>(...). If a class derives from DeflateStream(.net standard 2.0) and used in .net core 3.1, then the WriteAsync<T>(..) goes to infinite loop because:

-Since DeflateStream(.net standard 2.0) does not have WriteAsync<T>(..), the Stream.WriteAsync<T> is used.
-Stream.WriteAsync<T>(..) internally calls BeginWrite(..)
-BeginWrite(..) method of DeflateStream(.net core 3.1) internally calls WriteAsync<T>(..)

```csharp
//implement this in a .net standard 2.0 assembly
//all properties and methods simply call corresponding property or method in the base
public class MyStream : DeflateStream
{
    public override Task WriteAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
    {
        return base.WriteAsync(buffer, offset, count, cancellationToken);
    }

    //rest of code
}

//reference the assembly above from a .net core 3.1 project.

MyStream stream = new MyStream(new MemoryStream(), CompressionMode.Compress);

//the line below goes in an infinite loop
stream.WriteAsync(new byte[]{1,2}, 0, 2, new CancellationToken());

Author:	tahirkilic
Assignees:	-
Labels:	`area-System.IO`, `untriaged`
Milestone:	-

@adamsitnik I was able to confirm the problem with .NET Core 3.1, 5.0 and 6.0. @jeffhandley ### Summary

When a class derives from DeflateStream (compiled against .NET Standard 2.0, which lacks the WriteAsync(ReadOnlyMemory<byte>, CancellationToken) override) and is used on .NET Core 3.1+, calling WriteAsync enters an infinite loop. The call chain is: Stream.WriteAsync → BeginWrite → DeflateStream.BeginWrite → WriteAsync → back to Stream.WriteAsync. Confirmed by @adamsitnik on .NET Core 3.1, 5.0, and 6.0.

Expected Fix

Break the circular call chain in DeflateStream.BeginWrite. When BeginWrite detects it's being called from the base Stream.WriteAsync (e.g., by checking if the concrete type overrides WriteAsync with the old byte[] signature but not the new ReadOnlyMemory<byte> signature), it should call the underlying compression implementation directly instead of dispatching back through WriteAsync. A similar pattern exists in other Stream subclasses that needed to handle the .NET Standard 2.0 → .NET Core migration.

Test Coverage

Add a test with a class derived from DeflateStream that only overrides WriteAsync(byte[], int, int, CancellationToken).
Call the derived stream's WriteAsync(ReadOnlyMemory<byte>, CancellationToken) and verify it completes without hanging.
Test both DeflateStream and GZipStream (which uses DeflateStream internally).

Repro

// In a .NET Standard 2.0 assembly:
public class MyStream : DeflateStream
{
    public M...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes dotnet/runtime#58039

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo.

- Added tests to reproduce infinite loop with derived streams - Fixed DeflateStream.BeginWrite to call WriteAsyncMemory directly - Fixed GZipStream.BeginWrite to call WriteAsyncMemory directly - Tests verify that derived streams with only byte[] WriteAsync override don't hang Co-authored-by: jeffhandley <1031940+jeffhandley@users.noreply.github.com>

Co-authored-by: jeffhandley <1031940+jeffhandley@users.noreply.github.com>

Copilot

Pull request overview

Fixes a compatibility hang where BeginWrite in DeflateStream / GZipStream could recurse indefinitely when used from derived classes compiled against older reference assemblies (notably .NET Standard 2.0), by avoiding WriteAsync virtual dispatch from BeginWrite.

Changes:

Update DeflateStream.BeginWrite to call WriteAsyncMemory(...) directly (instead of WriteAsync(...)) to break the recursion cycle.
Update GZipStream.BeginWrite to delegate to _deflateStream.WriteAsyncMemory(...) directly for the same reason.
Add regression tests intended to validate “does not hang” behavior for derived streams.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File	Description
src/libraries/System.IO.Compression/src/System/IO/Compression/DeflateZLib/DeflateStream.cs	Breaks the BeginWrite → WriteAsync recursion by calling internal async implementation directly.
src/libraries/System.IO.Compression/src/System/IO/Compression/GZipStream.cs	Mirrors the BeginWrite fix for GZipStream by calling into DeflateStream’s internal async write path.
src/libraries/System.IO.Compression/tests/CompressionStreamUnitTests.Deflate.cs	Adds a regression test for derived DeflateStream async write behavior.
src/libraries/System.IO.Compression/tests/CompressionStreamUnitTests.Gzip.cs	Adds a regression test for derived GZipStream async write behavior.

Copilot · 2026-02-08T13:53:52Z

src/libraries/System.IO.Compression/tests/CompressionStreamUnitTests.Gzip.cs

+        public async Task DerivedStream_WithByteArrayWriteAsync_DoesNotHang()
+        {
+            // This test simulates a .NET Standard 2.0 derived GZipStream that only overrides
+            // WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,
+            // calling WriteAsync should not enter an infinite loop.
+            using (var ms = new MemoryStream())
+            using (var compressor = new DerivedGZipStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))
+            {
+                byte[] data = new byte[] { 1, 2, 3, 4, 5 };
+
+                // This should complete without hanging
+                var writeTask = compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).AsTask();
+
+                // Set a timeout to detect infinite loop
+                var completedTask = await Task.WhenAny(writeTask, Task.Delay(TimeSpan.FromSeconds(5)));
+
+                Assert.Same(writeTask, completedTask);
+                await writeTask; // Ensure no exceptions
+                Assert.True(compressor.WriteAsyncCalled);
+            }


Task.WhenAny(writeTask, Task.Delay(...)) detects a hang but doesn’t terminate writeTask. If the recursion bug regresses, the test may fail but leave a runaway operation that can affect subsequent tests. Prefer isolating this with RemoteExecutor and a short timeout, or another approach that guarantees termination on failure.

Suggested change

public async Task DerivedStream_WithByteArrayWriteAsync_DoesNotHang()

{

// This test simulates a .NET Standard 2.0 derived GZipStream that only overrides

// WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,

// calling WriteAsync should not enter an infinite loop.

using (var ms = new MemoryStream())

using (var compressor = new DerivedGZipStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))

{

byte[] data = new byte[] { 1, 2, 3, 4, 5 };

// This should complete without hanging

var writeTask = compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).AsTask();

// Set a timeout to detect infinite loop

var completedTask = await Task.WhenAny(writeTask, Task.Delay(TimeSpan.FromSeconds(5)));

Assert.Same(writeTask, completedTask);

await writeTask; // Ensure no exceptions

Assert.True(compressor.WriteAsyncCalled);

}

public void DerivedStream_WithByteArrayWriteAsync_DoesNotHang()

{

// This test simulates a .NET Standard 2.0 derived GZipStream that only overrides

// WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,

// calling WriteAsync should not enter an infinite loop.

using RemoteInvokeHandle handle = RemoteExecutor.Invoke(() =>

{

using (var ms = new MemoryStream())

using (var compressor = new DerivedGZipStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))

{

byte[] data = new byte[] { 1, 2, 3, 4, 5 };

// This should complete without hanging

compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).GetAwaiter().GetResult();

Assert.True(compressor.WriteAsyncCalled);

}

},

new RemoteInvokeOptions

{

TimeOut = 5000

});

Copilot · 2026-02-08T13:53:52Z

src/libraries/System.IO.Compression/src/System/IO/Compression/DeflateZLib/DeflateStream.cs

+            // If a derived class (compiled against .NET Standard 2.0 where DeflateStream doesn't override
+            // WriteAsync(byte[], ...)) calls base.WriteAsync, it goes to Stream.WriteAsync, which calls
+            // BeginWrite. If BeginWrite then calls WriteAsync, it creates a loop.


The comment says “where DeflateStream doesn’t override WriteAsync(byte[], ...)”, but this type does override WriteAsync(byte[],...) in this assembly. To avoid confusion, please reword to clarify that the issue is with derived types compiled against older reference assemblies (e.g., netstandard2.0) where the base call binds to Stream.WriteAsync and thus routes through Begin/EndWrite.

Suggested change

// If a derived class (compiled against .NET Standard 2.0 where DeflateStream doesn't override

// WriteAsync(byte[], ...)) calls base.WriteAsync, it goes to Stream.WriteAsync, which calls

// BeginWrite. If BeginWrite then calls WriteAsync, it creates a loop.

// For derived types compiled against older reference assemblies (for example, .NET Standard 2.0)

// where a base.WriteAsync(byte[], ...) call binds to Stream.WriteAsync, the call flows into

// BeginWrite. If this BeginWrite implementation then called WriteAsync(byte[], ...), it would

// re-enter that base implementation and create a loop.

Copilot · 2026-02-08T13:53:53Z

src/libraries/System.IO.Compression/src/System/IO/Compression/GZipStream.cs

+            // If a derived class (compiled against .NET Standard 2.0 where GZipStream doesn't override
+            // WriteAsync(byte[], ...)) calls base.WriteAsync, it goes to Stream.WriteAsync, which calls
+            // BeginWrite. If BeginWrite then calls WriteAsync, it creates a loop.


The comment says “where GZipStream doesn’t override WriteAsync(byte[], ...)”, but GZipStream does override WriteAsync(byte[],...) in this assembly. Please reword to make it explicit this is about code compiled against older reference assemblies (netstandard2.0) where the base call binds to Stream.WriteAsync and can re-enter BeginWrite.

Suggested change

// If a derived class (compiled against .NET Standard 2.0 where GZipStream doesn't override

// WriteAsync(byte[], ...)) calls base.WriteAsync, it goes to Stream.WriteAsync, which calls

// BeginWrite. If BeginWrite then calls WriteAsync, it creates a loop.

// If a derived class (compiled against older reference assemblies, e.g. netstandard2.0,

// where GZipStream was not declared to override WriteAsync(byte[], ...)) calls base.WriteAsync,

// the call binds to Stream.WriteAsync, which calls BeginWrite. If BeginWrite then calls WriteAsync,

// it creates a loop.

Copilot · 2026-02-08T13:53:53Z

src/libraries/System.IO.Compression/tests/CompressionStreamUnitTests.Deflate.cs

+        [Fact]
+        public async Task DerivedStream_WithByteArrayWriteAsync_DoesNotHang()
+        {
+            // This test simulates a .NET Standard 2.0 derived DeflateStream that only overrides
+            // WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,
+            // calling WriteAsync should not enter an infinite loop.
+            using (var ms = new MemoryStream())
+            using (var compressor = new DerivedDeflateStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))
+            {
+                byte[] data = new byte[] { 1, 2, 3, 4, 5 };
+
+                // This should complete without hanging
+                var writeTask = compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).AsTask();
+
+                // Set a timeout to detect infinite loop
+                var completedTask = await Task.WhenAny(writeTask, Task.Delay(TimeSpan.FromSeconds(5)));
+
+                Assert.Same(writeTask, completedTask);
+                await writeTask; // Ensure no exceptions
+                Assert.True(compressor.WriteAsyncCalled);
+            }


The new test doesn’t actually simulate the reported .NET Standard 2.0 scenario. DerivedDeflateStreamWithByteArrayWriteAsync.WriteAsync(byte[],...) calls base.WriteAsync(...), but in this build DeflateStream does override WriteAsync(byte[],...), so the base call binds to DeflateStream.WriteAsync rather than Stream.WriteAsync, and the BeginWrite/WriteAsync recursion can’t occur. Consider generating the derived type via Reflection.Emit (or a small netstandard2.0 test asset) so the override does a non-virtual call to Stream.WriteAsync(byte[],...), which will exercise BeginWrite on DeflateStream and reproduce the original hang.

Copilot · 2026-02-08T13:53:53Z

src/libraries/System.IO.Compression/tests/CompressionStreamUnitTests.Deflate.cs

+        public async Task DerivedStream_WithByteArrayWriteAsync_DoesNotHang()
+        {
+            // This test simulates a .NET Standard 2.0 derived DeflateStream that only overrides
+            // WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,
+            // calling WriteAsync should not enter an infinite loop.
+            using (var ms = new MemoryStream())
+            using (var compressor = new DerivedDeflateStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))
+            {
+                byte[] data = new byte[] { 1, 2, 3, 4, 5 };
+
+                // This should complete without hanging
+                var writeTask = compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).AsTask();
+
+                // Set a timeout to detect infinite loop
+                var completedTask = await Task.WhenAny(writeTask, Task.Delay(TimeSpan.FromSeconds(5)));
+
+                Assert.Same(writeTask, completedTask);
+                await writeTask; // Ensure no exceptions
+                Assert.True(compressor.WriteAsyncCalled);
+            }


Task.WhenAny(writeTask, Task.Delay(...)) will throw quickly on a hang, but it doesn’t stop writeTask. If the regression reappears, the runaway recursion may continue consuming thread pool/CPU and destabilize the rest of the test run. Prefer running the repro in RemoteExecutor with a short RemoteInvokeOptions.TimeOut, or otherwise structure the repro so the hung work is isolated/terminated.

Suggested change

public async Task DerivedStream_WithByteArrayWriteAsync_DoesNotHang()

{

// This test simulates a .NET Standard 2.0 derived DeflateStream that only overrides

// WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,

// calling WriteAsync should not enter an infinite loop.

using (var ms = new MemoryStream())

using (var compressor = new DerivedDeflateStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))

{

byte[] data = new byte[] { 1, 2, 3, 4, 5 };

// This should complete without hanging

var writeTask = compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).AsTask();

// Set a timeout to detect infinite loop

var completedTask = await Task.WhenAny(writeTask, Task.Delay(TimeSpan.FromSeconds(5)));

Assert.Same(writeTask, completedTask);

await writeTask; // Ensure no exceptions

Assert.True(compressor.WriteAsyncCalled);

}

public void DerivedStream_WithByteArrayWriteAsync_DoesNotHang()

{

var options = new RemoteInvokeOptions

{

TimeOut = 5000

};

RemoteExecutor.Invoke(static () =>

{

// This test simulates a .NET Standard 2.0 derived DeflateStream that only overrides

// WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,

// calling WriteAsync should not enter an infinite loop.

using (var ms = new MemoryStream())

using (var compressor = new DerivedDeflateStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))

{

byte[] data = new byte[] { 1, 2, 3, 4, 5 };

// This should complete without hanging; if it hangs, the RemoteExecutor timeout will terminate the process.

compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).AsTask().GetAwaiter().GetResult();

Assert.True(compressor.WriteAsyncCalled);

}

return RemoteExecutor.SuccessExitCode;

}, options).Dispose();

Copilot · 2026-02-08T13:53:53Z

src/libraries/System.IO.Compression/tests/CompressionStreamUnitTests.Gzip.cs

+        [Fact]
+        public async Task DerivedStream_WithByteArrayWriteAsync_DoesNotHang()
+        {
+            // This test simulates a .NET Standard 2.0 derived GZipStream that only overrides
+            // WriteAsync(byte[], int, int, CancellationToken). When used in .NET Core 3.1+,
+            // calling WriteAsync should not enter an infinite loop.
+            using (var ms = new MemoryStream())
+            using (var compressor = new DerivedGZipStreamWithByteArrayWriteAsync(ms, CompressionMode.Compress))
+            {
+                byte[] data = new byte[] { 1, 2, 3, 4, 5 };
+
+                // This should complete without hanging
+                var writeTask = compressor.WriteAsync(new ReadOnlyMemory<byte>(data)).AsTask();
+
+                // Set a timeout to detect infinite loop
+                var completedTask = await Task.WhenAny(writeTask, Task.Delay(TimeSpan.FromSeconds(5)));
+
+                Assert.Same(writeTask, completedTask);
+                await writeTask; // Ensure no exceptions
+                Assert.True(compressor.WriteAsyncCalled);
+            }


The new test doesn’t actually simulate the reported .NET Standard 2.0 scenario. DerivedGZipStreamWithByteArrayWriteAsync.WriteAsync(byte[],...) calls base.WriteAsync(...), but in this build GZipStream overrides WriteAsync(byte[],...), so the base call won’t bind to Stream.WriteAsync and won’t exercise the BeginWrite recursion this PR fixes. Consider using Reflection.Emit (or a netstandard2.0-compiled test asset) so the override can do a non-virtual call to Stream.WriteAsync(byte[],...) and reproduce the original hang.

stephentoub · 2026-02-08T18:45:13Z

@jeffhandley, this is fixing one issue at the expense of introducing another. If BeginWrite calls to the private non-overidable method, then a derived type that was overriding WriteAsync will no longer have its behaviors respected as part of BeginWrite calls, e.g. if WriteAsync was overridden to throttle or keep track of the number of calls or whatever, using BeginWrite will now bypass that logic. That's a fairly substantial breaking change.

stephentoub · 2026-02-08T18:55:57Z

Also, if we did want to fix it this way, wouldn't the same issue exist for read?

And do the tests actually protect against this?

jeffhandley · 2026-02-08T21:13:20Z

Thanks, @stephentoub. Closing for now as it was low-pri. Good catches on those points.

Initial plan

d6855be

Copilot AI assigned Copilot and jeffhandley Feb 8, 2026

Copilot started work on behalf of jeffhandley February 8, 2026 10:41 View session

github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Feb 8, 2026

Copilot AI and others added 3 commits February 8, 2026 10:49

Fix trailing whitespace in test file

ffd6460

Co-authored-by: jeffhandley <1031940+jeffhandley@users.noreply.github.com>

Remove remaining trailing whitespace

ba257f7

Co-authored-by: jeffhandley <1031940+jeffhandley@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix infinite loop in DeflateStream's WriteAsync method~~ Fix infinite loop in DeflateStream/GZipStream BeginWrite with .NET Standard 2.0 derived classes Feb 8, 2026

Copilot AI requested a review from jeffhandley February 8, 2026 11:13

Copilot finished work on behalf of jeffhandley February 8, 2026 11:13

jeffhandley approved these changes Feb 8, 2026

View reviewed changes

jeffhandley marked this pull request as ready for review February 8, 2026 13:43

Copilot AI review requested due to automatic review settings February 8, 2026 13:43

Copilot started reviewing on behalf of jeffhandley February 8, 2026 13:44 View session

jeffhandley requested review from ViveliDuCh and adamsitnik February 8, 2026 13:45

Copilot AI reviewed Feb 8, 2026

View reviewed changes

jeffhandley closed this Feb 8, 2026

jeffhandley added area-System.IO.Compression and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Feb 8, 2026

jeffhandley mentioned this pull request Feb 8, 2026

DeflateStream as a base class causes infinite loop in async scenario. #58039

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix infinite loop in DeflateStream/GZipStream BeginWrite with .NET Standard 2.0 derived classes#124143

Fix infinite loop in DeflateStream/GZipStream BeginWrite with .NET Standard 2.0 derived classes#124143
Copilot wants to merge 4 commits intomainfrom
copilot/fix-deflatestream-infinite-loop

Copilot AI commented Feb 8, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Feb 8, 2026

Uh oh!

Copilot AI Feb 8, 2026

Uh oh!

Copilot AI Feb 8, 2026

Uh oh!

Copilot AI Feb 8, 2026

Uh oh!

Copilot AI Feb 8, 2026

Uh oh!

Copilot AI Feb 8, 2026

Uh oh!

stephentoub commented Feb 8, 2026

Uh oh!

stephentoub commented Feb 8, 2026

Uh oh!

jeffhandley commented Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

-            // If a derived class (compiled against .NET Standard 2.0 where DeflateStream doesn't override
-            // WriteAsync(byte[], ...)) calls base.WriteAsync, it goes to Stream.WriteAsync, which calls
-            // BeginWrite. If BeginWrite then calls WriteAsync, it creates a loop.
+            // For derived types compiled against older reference assemblies (for example, .NET Standard 2.0)
+            // where a base.WriteAsync(byte[], ...) call binds to Stream.WriteAsync, the call flows into
+            // BeginWrite. If this BeginWrite implementation then called WriteAsync(byte[], ...), it would
+            // re-enter that base implementation and create a loop.

-            // If a derived class (compiled against .NET Standard 2.0 where GZipStream doesn't override
-            // WriteAsync(byte[], ...)) calls base.WriteAsync, it goes to Stream.WriteAsync, which calls
-            // BeginWrite. If BeginWrite then calls WriteAsync, it creates a loop.
+            // If a derived class (compiled against older reference assemblies, e.g. netstandard2.0,
+            // where GZipStream was not declared to override WriteAsync(byte[], ...)) calls base.WriteAsync,
+            // the call binds to Stream.WriteAsync, which calls BeginWrite. If BeginWrite then calls WriteAsync,
+            // it creates a loop.

Conversation

Copilot AI commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changes

Type of change

Expected Fix

Test Coverage

Repro

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Feb 8, 2026

Uh oh!

stephentoub commented Feb 8, 2026

Uh oh!

jeffhandley commented Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Copilot AI commented Feb 8, 2026 •

edited

Loading