Fix PyPy snappy decompression BufferError in CI

[Copilot]

(found by monorepo ci)

Summary

• investigate failing GitHub Actions job ci / test (ubuntu-latest, pypy3.11) (run 26149297732, job 76912461018)
• fix dissect.util.compression.snappy.decompress by releasing the temporary BytesIO buffer view before writing back to the same stream
• preserve existing decompression logic while avoiding PyPy's BufferError: Existing exports of data: object cannot be re-sized

Root cause

PyPy keeps exported BytesIO buffers alive longer than CPython in this code path. The previous implementation read copy data via dst.getbuffer()[...].tobytes() and then resized dst with dst.write(...) in the same loop. On PyPy 7.3.22 this triggers BufferError because the buffer export is still active when resizing. The offending PR is https://github.com/pypy/pypy/pull/5407/changes.

[twiggler]

@copilot why was this not a problem before? Did something change in pypy 3.11?

[Copilot]

Good question — I checked the logs, and the same repo SHA (4d86c1b) passed earlier on PyPy 7.3.21 but failed later on PyPy 7.3.22 (still Python 3.11.15). So this path was relying on behavior that happened to work before: the temporary BytesIO export from getbuffer() was dropped soon enough. In newer PyPy it stays alive across the subsequent dst.write(...) resize check, which raises BufferError. Commit b09ffce fixes that by explicitly releasing the buffer view before writing.

[twiggler]

@copilot I found this PR which is likely the root cause: https://github.com/pypy/pypy/pull/5407/changes

Please confirm and explain

[Copilot]

Confirmed — that PR is very likely the root cause. In our CI, the failing run switched from PyPy 7.3.21 to 7.3.22, and your linked PR adds stricter active-export tracking (_exports) plus _check_exports(...) on bytearray-resizing/mutating paths, raising BufferError while a view is still exported. Our code was taking dst.getbuffer()[...].tobytes() and then immediately doing dst.write(...); with the stricter export checks, that now reliably raises until the view is released. That is exactly why b09ffce fixes it by releasing the buffer view before writing.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 0.00%. Comparing base (dde4491) to head (a6b4532).

Files with missing lines	Patch %	Lines
dissect/util/compression/snappy.py	0.00%	4 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #128   +/-   ##
=====================================
  Coverage   0.00%   0.00%           
=====================================
  Files         29      29           
  Lines       2103    2106    +3     
=====================================
- Misses      2103    2106    +3     

Flag	Coverage Δ
unittests	0.00% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[codspeed-hq]

Merging this PR will not alter performance

✅ 33 untouched benchmarks

---

_{Comparing copilot/fix-ci-test-ubuntu-latest-pypy3-11 (a6b4532) with main (dde4491)}

[JSCU-CNI]

Maybe add a comment to the new try/finally to explain why this was added, and perhaps a reference to this PR or PyPy?

[twiggler]

I will add a reference to the python documentation,
where is is explicitly stated that

"Many objects take special actions when a view is held on them (for example, a bytearray would temporarily forbid resizing)"

https://docs.python.org/3/library/stdtypes.html#memoryview:~:text=release

So I think calling release is not a workaround around some PyPy quirk, but necessary in general; we were just "lucky" before.