Describe the bug
Under free-threaded Python 3.14 (3.14t), test_sidecar.py::test_fsspec_chunked_open_resolves_sidecar_overview fails with a zlib decompression error when reading a COG sidecar overview through the chunked (dask) path:
zlib.error: Error -3 while decompressing data: incorrect header check
On Windows the same test also surfaces ValueError: I/O operation on closed file.
The failure showed up on the new 3.14t CI lane (PR #3360). It reproduces on ubuntu-latest and windows-latest but not macos-latest, and never on the GIL-enabled builds (3.12, 3.13, 3.14 all pass). 9689+ other tests pass.
Likely cause
The test opens a COG with chunks=16 and then materializes .values, so tiles decompress in parallel on dask's threaded scheduler. The error pattern (corrupted zlib stream plus a closed-file error) points to a shared file handle and/or zlib decompressor used by concurrent tile reads without locking. zlib decompress objects are not thread-safe; the GIL was serializing these reads, so the race only appears once it is gone. macOS passing is consistent with a timing-dependent race rather than a platform-specific bug.
Where to look
xrspatial/geotiff/tests/integration/test_sidecar.py::test_fsspec_chunked_open_resolves_sidecar_overview- the chunked read path:
xrspatial/geotiff/_backends/dask.py and the tile decode helpers it calls (_decode.py, _compression.py, _sources.py)
- anything that holds a single open file object or a single decompressor across tiles
Notes
This is pre-existing behavior, not caused by PR #3360, which only added 3.14t to the matrix. The 3.14t job is allowed-failure, so this does not block merges; it is the signal the lane was added to provide. This issue tracks the fix toward making the free-threaded lane green.
Describe the bug
Under free-threaded Python 3.14 (
3.14t),test_sidecar.py::test_fsspec_chunked_open_resolves_sidecar_overviewfails with a zlib decompression error when reading a COG sidecar overview through the chunked (dask) path:On Windows the same test also surfaces
ValueError: I/O operation on closed file.The failure showed up on the new
3.14tCI lane (PR #3360). It reproduces on ubuntu-latest and windows-latest but not macos-latest, and never on the GIL-enabled builds (3.12, 3.13, 3.14 all pass). 9689+ other tests pass.Likely cause
The test opens a COG with
chunks=16and then materializes.values, so tiles decompress in parallel on dask's threaded scheduler. The error pattern (corrupted zlib stream plus a closed-file error) points to a shared file handle and/orzlibdecompressor used by concurrent tile reads without locking.zlibdecompress objects are not thread-safe; the GIL was serializing these reads, so the race only appears once it is gone. macOS passing is consistent with a timing-dependent race rather than a platform-specific bug.Where to look
xrspatial/geotiff/tests/integration/test_sidecar.py::test_fsspec_chunked_open_resolves_sidecar_overviewxrspatial/geotiff/_backends/dask.pyand the tile decode helpers it calls (_decode.py,_compression.py,_sources.py)Notes
This is pre-existing behavior, not caused by PR #3360, which only added
3.14tto the matrix. The3.14tjob is allowed-failure, so this does not block merges; it is the signal the lane was added to provide. This issue tracks the fix toward making the free-threaded lane green.