Skip to content

stable_only=True does not reject HTTP/fsspec sources on non-VRT read paths #2821

@brendancol

Description

@brendancol

Describe the bug

open_geotiff(..., stable_only=True) is supposed to restrict reads to stable-tier sources, but it doesn't enforce that for HTTP/fsspec sources on the non-VRT paths.

reader.fsspec and reader.http are marked advanced in SUPPORTED_FEATURES (xrspatial/geotiff/_attrs.py:292-293). The stable_only check only runs on the VRT path, through _validate_stable_only_vrt. The eager non-VRT path calls _read_to_array directly (xrspatial/geotiff/__init__.py:959) and never re-checks the tier, and the dask path only forwards stable_only to read_vrt when the source ends in .vrt (xrspatial/geotiff/_backends/dask.py:208). For a plain HTTP or fsspec source, neither path rejects the advanced-tier reader.

Reproduction

Write a valid GeoTIFF into a memory:// fsspec store and call open_geotiff(path, stable_only=True). It succeeds on both the eager and dask paths, even though reader.fsspec is advanced. A local file under stable_only=True succeeds too, which is correct.

Expected behavior

With stable_only=True, the eager and dask non-VRT paths should reject advanced-tier HTTP/fsspec sources and raise the same error the VRT path raises (VRTStableSourcesOnlyError, a GeoTIFFAmbiguousMetadataError subclass), unless the caller passes allow_experimental_codecs=True. Local-file sources should keep working under stable_only=True.

Additional context

This makes the stability contract leaky: someone who sets stable_only=True to avoid advanced-tier readers can still get an HTTP/fsspec read.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions