Skip to content

Test ZipBytes archive boundaries instead of compressed size - #10041

Open
mkzung wants to merge 1 commit into
QuantConnect:masterfrom
mkzung:bug-10040-zip-byte-array-length
Open

mkzung wants to merge 1 commit into
QuantConnect:masterfrom
mkzung:bug-10040-zip-byte-array-length

Conversation

@mkzung

@mkzung mkzung commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

Description

Check the ZIP end record at the end of the returned byte array and compare the decompressed binary payload with the input fixture. The test protects against unused buffer capacity without assuming a platform-specific Deflate size.

On .NET 10.0.400, macOS arm64 produces 905,693 bytes for this fixture, matching the Windows expectation; the existing non-Windows assertion expects 906,121.

Related Issue

Fixes #10040.

Motivation and Context

A valid archive should pass the test when the runtime changes its compressed representation.

Requires Documentation Change

No.

How Has This Been Tested?

Pristine checkout and fresh Release build on macOS arm64, .NET 10.0.400, Python 3.11.15 with the project's pinned scientific dependencies.

  • All 14 compression tests pass.
  • Replacing ToArray() with GetBuffer() makes the new test fail; restoring ToArray() passes again.
  • The full main CI selection passes: 39,327 passed and 100 skipped. The same full selection passes again after restoring the production method.

Types of changes

  • Non-functional change (tests)

Checklist:

  • My code follows the code style of this project.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • My branch follows the naming convention bug-<issue#>-<description>.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ZipBytes length test fails on macOS with .NET 10.0.400

1 participant