Compression encoder tests fail on mobile platforms with DestinationTooSmall

Reasoning

Three compression encoder/decoder tests are failing consistently across all mobile platforms (iOS, tvOS, macCatalyst, Android) in the runtime-extra-platforms pipeline:

DeflateEncoderDecoderTests.RoundTrip_AllWindowLogs
ZLibEncoderDecoderTests.RoundTrip_AllWindowLogs
GZipEncoderDecoderTests.RoundTrip_AllWindowLogs

All three fail with the same assertion error: the encoder's Compress operation returns OperationStatus.DestinationTooSmall instead of OperationStatus.Done when testing with various window log sizes. This suggests that GetMaxCompressedLength() is returning an insufficient buffer size for certain window sizes on mobile platforms, or there is a platform-specific issue in the native compression library (zlib/brotli) integration.

The test code allocates a destination buffer using GetMaxCompressedLength(input.Length) and expects all data to compress in a single Compress call. The failure indicates the buffer is too small despite using the API's recommended size calculation.

This appears to be a product bug rather than a test incompatibility — the encoder API contract is not being honored on mobile platforms. The issue affects all compression formats (Deflate, ZLib, GZip) and all mobile architectures (arm64, x64, arm, x86).

Impact on platforms

Failing on all mobile platforms and architectures tested in build 1399212 (2026-04-28):

maccatalyst-x64 / OSX.15.Amd64.Open / exit code 1
maccatalyst-arm64 / OSX.15.Arm64.Open / exit code 1
iossimulator-x64 / OSX.15.Amd64.Open / exit code 1
iossimulator-arm64 / OSX.15.Arm64.Open / exit code 1
tvos-arm64 / osx.15.amd64.appletv.open / exit code 1
android-arm64 / Windows.11.Amd64.Android.Open / exit code 1
android-arm / Windows.11.Amd64.Android.Open / exit code 1
android-x64 / Windows.11.Amd64.Android.Open / exit code 1

Also confirmed failing in build 1397424 (2026-04-27).

Errors log

From maccatalyst-x64 Helix work item System.IO.Compression.Tests (console log):

Failed tests:
1) 	[FAIL] System.IO.Compression.DeflateEncoderDecoderTests.RoundTrip_AllWindowLogs
   Test name: System.IO.Compression.DeflateEncoderDecoderTests.RoundTrip_AllWindowLogs
   Assembly:  [System.IO.Compression.Tests, Version=11.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51]
   Exception messages: Assert.Equal() Failure: Values differ
Expected: Done
Actual:   DestinationTooSmall
   Exception stack traces:    at System.IO.Compression.EncoderDecoderTestBase.RoundTrip_AllWindowLogs()
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
   Execution time: 0.0011576

2) 	[FAIL] System.IO.Compression.ZLibEncoderDecoderTests.RoundTrip_AllWindowLogs
   Test name: System.IO.Compression.ZLibEncoderDecoderTests.RoundTrip_AllWindowLogs
   Assembly:  [System.IO.Compression.Tests, Version=11.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51]
   Exception messages: Assert.Equal() Failure: Values differ
Expected: Done
Actual:   DestinationTooSmall
   Exception stack traces:    at System.IO.Compression.EncoderDecoderTestBase.RoundTrip_AllWindowLogs()
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
   Execution time: 0.0002248

3) 	[FAIL] System.IO.Compression.GZipEncoderDecoderTests.RoundTrip_AllWindowLogs
   Test name: System.IO.Compression.GZipEncoderDecoderTests.RoundTrip_AllWindowLogs
   Assembly:  [System.IO.Compression.Tests, Version=11.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51]
   Exception messages: Assert.Equal() Failure: Values differ
Expected: Done
Actual:   DestinationTooSmall

First build it occurred

First observed (within the scanned window of ~20 builds) in build 1399212, which finished on 2026-04-28T07:31:50Z (commit 2ac6372). Also confirmed in build 1397424 (2026-04-27, commit 395fea5).

Note: This window represents the last ~8 days of builds. The true origin may be earlier if the test or underlying code was added/changed before 2026-04-20.

Occurrences in scanned window: Present in all mobile library test jobs across both builds checked (100% failure rate for these tests on mobile platforms).

Recommended action

Area owner: @dotnet/area-system-io-compression should investigate why GetMaxCompressedLength returns an insufficient buffer size on mobile platforms.
Possible root causes:
- Platform-specific difference in zlib's compressBound calculation
- Mobile-specific compiler or packing issue affecting struct sizes or buffer calculations
- Recent change to the encoder/decoder implementation that broke mobile platform assumptions
Investigation steps:
- Run the test locally on a mobile simulator with verbose logging to see which window log value triggers the failure
- Compare GetMaxCompressedLength output between desktop and mobile for the same input size
- Check if this is related to native zlib version differences on mobile vs desktop
- Review recent commits to src/libraries/System.IO.Compression and related native code
Short-term workaround: If the investigation will take time, consider temporarily skipping these three tests on mobile platforms with [ActiveIssue] to unblock the pipeline, but the underlying product bug must be fixed — users relying on these APIs on mobile would hit the same buffer sizing issue.

Note

🔒 Integrity filter blocked 3 items

The following items were blocked because they don't meet the GitHub integrity level.

#125825 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#56828 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#29927 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Mobile Platform Failure Scanner · ● 7.6M · ◷

@vitek-karas

Tagging subscribers to 'os-maccatalyst': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

@vitek-karas

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

@vitek-karas

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

@vitek-karas

Tagging subscribers to 'os-tvos': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

@karelz

Tagging subscribers to this area: @karelz, @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Build 1403076 occurrence (2026-04-30)

The compression encoder test failures (DestinationTooSmall) are still present in build 1403076 which completed on 2026-04-30T10:36:57Z.

Confirmed failing on:

android-arm (Helix job a15256d6) - 3 failures
android-arm64
android-x64
android-x86
maccatalyst-arm64
maccatalyst-x64
iossimulator-x64
iossimulator-arm64
tvos-arm64

Same three tests failing: DeflateEncoderDecoderTests.RoundTrip_AllWindowLogs, ZLibEncoderDecoderTests.RoundTrip_AllWindowLogs, GZipEncoderDecoderTests.RoundTrip_AllWindowLogs

Generated by Mobile Platform Failure Scanner · ● 3.1M · ◷

Improve clarity in mobile scanner workflow issues and PRs (#127568)

Skip RoundTrip_AllWindowLogs compression tests on mobile platforms

This is likely a defect in the new .NET 11 APIs -> milestone 11.0.0.

Improve clarity in mobile scanner workflow issues and PRs (#127568)

[mobile] Disable RoundTrip_AllWindowLogs on iOS / tvOS / MacCatalyst …

@BrzVlad

@BrzVlad this is in 11.0 milestone, ZBB is next Friday. Will you make it by that time?

I'll take a look next week to see what can be done here.

@rzikm

The problem here is that the api exposes statically the method GetMaxCompressedLength(long inputLength). This currently calls compressBound(inputLength) which returns the conservative size if using the default compression parameters. Our API enables configuring the window size and other parameters, which affects the compress size. Using such compression parameters could result in more data generated than the size returned by GetMaxCompressedLength. It seems like zlib offers the method deflateBound that receives both the input length as well as the parameters of the compression. Our .NET api doesn't expose this. This means that, IMO, a proper fix would be for GetMaxCompressedLength to be an instance method on DeflateEncoder so that we can obtain the right size from the library.

This issue is facilitated by mobile not using zlib-ng from our sources. So we are left with whatever zlib version the iOS/Android provides for us. I can get AI to lookup various sources and generate a static formula for GetMaxCompressedLength that should work everywhere, but it is not really a theoretically reliable approach. I guess there is also the possibility of using the in tree zlib-ng on mobile and take the regression in size of ~100KB maybe. Any suggestion on what approach should we take ? cc @rzikm

More context and I believe the culprit for this regression: #127081

#132274

Fix DeflateEncoder.GetMaxCompressedLength conservative bound (#132274)

Navigation Menu

Repository navigation

Compression encoder tests fail on mobile platforms with DestinationTooSmall #127563

Reasoning

Impact on platforms

Errors log

First build it occurred

Recommended action

Build 1403076 occurrence (2026-04-30)

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Compression encoder tests fail on mobile platforms with DestinationTooSmall #127563

Description

Reasoning

Impact on platforms

Errors log

First build it occurred

Recommended action

Activity

dotnet-policy-service commented on Apr 29, 2026

dotnet-policy-service commented on Apr 29, 2026

dotnet-policy-service commented on Apr 29, 2026

dotnet-policy-service commented on Apr 29, 2026

dotnet-policy-service commented on Apr 29, 2026

github-actions commented on May 1, 2026

Build 1403076 occurrence (2026-04-30)

5 remaining items

jkotas commented on May 7, 2026

karelz commented on Aug 6, 2026

BrzVlad commented on Aug 6, 2026

BrzVlad commented on Aug 10, 2026

BrzVlad commented on Aug 10, 2026

BrzVlad commented on Aug 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions