Fix missing path prefix in next page links in GET items response

[anayeaye]

What

The dynamically produced next page link in an item search response (i.e. /collections/{collection_id}/items) is invalid when the API is deployed with a path prefix. The solution is likely upstream so this ticket involves working with stac-fastapi and pgstac.

Report

it seems the pagination of the items is not configured correctly, so if you go to, e.g.:
https://openveda.cloud/api/stac/collections/no2-monthly/items
when you look at the "rel":"next" which indicates the link to fetch the next set of items, it does not have /api/stac/ in the path. "href":"https://openveda.cloud/collections/no2-monthly/items?token=next:no2-monthly:OMI_trno2_0.10x0.10_202212_Col3_V4.nc" so it seems our client is able to fetch the first 10 items, and then runs into a "forbidden" location

AC

• next page link is valid in item search response

[smohiudd]

Looking at fast api pgstac, the next and previous links are using self.url while other links are using self.resolve https://github.com/stac-utils/stac-fastapi-pgstac/blob/2.5.0/stac_fastapi/pgstac/models/links.py#L132. Is self.resolve preserving the path prefix while self.url isnt?

cc: @vincentsarago

[vincentsarago]

👍 we should fix this in stac-fastapi-pgstac 🙏

[smohiudd]

PR in stac-fastapi-pgstac stac-utils/stac-fastapi-pgstac#164

[anayeaye]

@vincentsarago @smohiudd does this mean we need to update our runtime to install stac-fastapi-pgstac instead of the core stac-fastapi.pgstac that we currently use? Will we need other modifications?

[smohiudd]

We discovered the issue is not with stac-fastapi-pgstac but with how we were passing urls to origins in Cloudfront. The fix is in veda-routes: https://github.com/NASA-IMPACT/veda-routes/pull/38

[anayeaye]

We deployed the changes to production and tested