stac-utils / stac-fastapi-elasticsearch-opensearch

Elasticsearch backend for stac-fastapi with Opensearch support.
https://stac-utils.github.io/stac-fastapi-elasticsearch-opensearch
MIT License
24 stars 14 forks source link

stac-fastapi-core does not support configuring a STAC application with common extensions disabled #263

Open sirosen opened 1 month ago

sirosen commented 1 month ago

Describe the bug

When attempting to define a stac-fastapi-core-based application with the Query Extension disabled, I found that stac-fastapi-core would emit an attribute error and crashfail. Specifically, the logic for handling a POST Search request here: https://github.com/stac-utils/stac-fastapi-elasticsearch-opensearch/blob/49fecf95a986ea5cca60af60d6b16a194cd23439/stac_fastapi/core/stac_fastapi/core/core.py#L566

I found that this also happens with the sortby and token pagination extensions. Removing these makes the application inoperable.

To Reproduce

  1. Create a new application, e.g., based off of the mongodb example
  2. Remove the QueryExtension from the application's extensions
  3. Start the app (it will start)
  4. Send any valid POST Search
  5. :boom:

Expected behavior

With Query disabled, searches should function. The same holds for Sort and Token Pagination, but the case is clearest with Query (which is deprecated).

Additional context

I'm experimenting with building an application for my team, so I don't have a lot of knowledge around STAC. We're still learning the spec(s) and trying things out. For now, we're trying to get a very early stage prototype up and running, so I've implemented this very clumsy hack:

class CustomizedCoreClient(CoreClient):
    async def post_search(self, search_request, request):
        object.__setattr__(search_request, "query", None)
        object.__setattr__(search_request, "sortby", None)
        object.__setattr__(search_request, "token", None)
        return await super().post_search(search_request, request)

I think the best pattern for the stac-fastapi-core code would be to check with hasattr(...) or three-argument getattr(..., ..., None).

I'm happy to contribute a PR with this sort of fix if it would be welcome.

jonhealy1 commented 1 month ago

Hi thanks for bringing this to our attention. Feel free to make a pr. This should definitely be fixed.

jamesfisher-gis commented 1 month ago

I have been working on an adjacent issue and have added a condition for when an extension is enabled/disabled here #267. Maybe it is useful. Let me know if you have any suggestions for this approach.