CMR-STAC returns HLS granules with only a `metadata` asset

[spkearney]

Two main issues:
1) The CMR-STAC does not include the 36 band assets for certain dates when the search window changes
2) For the granule HLS.S30.T13TDF.2026215T174911.v2.0, no band assets are present via CMR-STAC search, but they exist on the CMR-UMM record and can be downloaded at https://search.earthdata.nasa.gov/

See details in the report below.


All observations made 2026-08-13 UTC
against https://cmr.earthdata.nasa.gov/stac/LPCLOUD, collection
HLSS30.v2.0. Everything below is reproducible with curl alone.

Summary

CMR-STAC intermittently returns HLSS30 v2.0 items whose assets object contains
only the metadata entry — none of the 36 band assets (B01…B12, B8A,
Fmask, SZA, SAA, VZA, VAA, plus their s3_* direct-access twins) that
the same collection normally emits.

The underlying data is present and downloadable. The granule's own UMM record
lists all 18 GET DATA .tif URLs, and those URLs resolve normally. Only the
STAC representation is missing them.

This is silent for STAC-driven clients. stackstac.stack() drops an item that
has none of the requested assets rather than raising, so a time series simply
comes up short with no error anywhere. In our pipeline a search returning 134
items produced a 131-item stack, losing three dates.

Two variants exist:
1. Depends on how much the query matched
Granule HLS.S30.T13TDF.2026215T174911.v2.0 (2026-08-03), with
bbox=-105.15301221016712,40.89905822203558,-105.00034604682511,40.998426730404304:

`datetime` range | `context.matched` | assets returned
`2025-11-01` → `2026-08-13` | 65 | `['metadata']`
`2026-06-01` → `2026-08-13` | 17 | `['metadata']`
`2026-07-27` → `2026-08-13` | 3 | full (37)
`2026-08-02` → `2026-08-05` | 1 | full (37)

Stable across repeated calls. Not a paging artifact: with limit=10 over the
full range, the granule appears on page 7 and is still ['metadata'], and
following rel="next" to exhaustion returns every matched item exactly once
(verified against context.matched).

# metadata-only
curl -s 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?&collections=HLSS30.v2.0&limit=100&bbox=-105.15301221016712,40.89905822203558,-105.00034604682511,40.998426730404304&datetime=2025-11-01T00:00:00Z/2026-08-13T00:00:00Z' \
| jq '.features[] | select(.id=="HLS.S30.T13TDF.2026215T174911.v2.0") | .assets | keys'

# full assets, same granule
curl -s 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?&collections=HLSS30.v2.0&limit=100&bbox=-105.15301221016712,40.89905822203558,-105.00034604682511,40.998426730404304&datetime=2026-08-02T00:00:00Z/2026-08-05T00:00:00Z' \
| jq '.features[] | select(.id=="HLS.S30.T13TDF.2026215T174911.v2.0") | .assets | keys | length'


2. Affects every granule on a specific date, under every query form
For 2026-07-29, all 12 S30 granules in the region returned ['metadata']:

curl -s 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/search?&collections=HLSS30.v2.0&limit=100&bbox=-106.3,40.4,-104.7,41.6&datetime=2026-07-29T00:00:00Z/2026-07-30T00:00:00Z' \
| jq '.features[] | {id, assets: (.assets|keys)}'

HLS.S30.T13TEG.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TDG.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TCG.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TEF.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TDF.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TCF.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TEE.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TDE.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TCE.2026210T174909.v2.0 ["metadata"]
HLS.S30.T13TDG.2026210T180751.v2.0 ["metadata"]
HLS.S30.T13TCG.2026210T180751.v2.0 ["metadata"]
HLS.S30.T13TCF.2026210T180751.v2.0 ["metadata"]

Here the narrow-window workaround does not help — the single-item endpoint
is equally affected:

curl -s 'https://cmr.earthdata.nasa.gov/stac/LPCLOUD/collections/HLSS30_2.0/items/HLS.S30.T13TDF.2026210T174909.v2.0' \
| jq '.assets | keys'
# -> ["metadata"]

[LP DAAC - dgolon]

Hi @spkearney We are looking into this and will report back when we have an answer. Thanks -- Danielle