MODIS collection errors

[JonDHo]

There seem to currently be various issues with STAC records, but I thought I would add this as another report as it doesn't relate to the HLS issues reported previously.

The /items endpoint for some MODIS collections fails completely and searches often fail. For example, the collection endpoint at https://cmr.earthdata.nasa.gov/stac/OB_DAAC/collections/MODISA_L2_OC_R2022.0 works, but https://cmr.earthdata.nasa.gov/stac/OB_DAAC/collections/MODISA_L2_OC_R2022.0/items returns the "Oops! Something has gone wrong." error.

The same goes for other MODIS collections like:

• MODISA_L2_IOP_R2022.0/items
• MODIST_L2_IOP_R2022.0/items
• MODIST_L2_OC_R2022.0/items

but the SST collections work:

• MODIST_L2_SST_R2019.0/items
• MODISA_L2_SST_R2019.0/items

I frequently get the "Oops!" error when searching using PySTAC and PySTAC Client as well (which should be using POST requests).

[aliciaaleman]

@JonDHo We have a fix working through our test environment that may resolve some of these issues but we'll confirm before closing this out.

[earthdata-github-robot]

(Comment from Eudoro Olivares Raniolo):

The error is coming from a graphql typing issue 

Int cannot represent non-integer value

on the cloudCover field. The linked ticket should fix that problem as it propagates into production Wed December 4th

[eudoroolivares2016]

This is now be fixed in production all those links have valid responses. For those wondering it was an issue with a type in an upstream dependency that cmr-stac has

[JonDHo]

Thanks. I can confirm that this is now working.

In my testing, I note that the number of features returned per page has now moved from the numberReturned value to the context object. It appears that the context extension is being or has been deprecated (radiantearth/stac-api-spec#396). Hopefully if the context object is ultimately removed, it will be possible to add back in the numberReturned and numberMatched values.