Endpoint /collections completely broken and returning error in wrong format

[christophfriedrich]

Currently, https://openeo.mundialis.de/api/v1.0/collections replies with:

[
  {
    "description": "An internal error occurred while catching mapset from location nc_spm_08!"
  }, 
  400
]

Aside from that it would be nice if this error wouldn't be there at all (:wink:), there are a couple of issues with that error response:

1. This is not a JSON error object as described in the Error Handling paragraph of the spec. That paragraph is only indicated as "SHOULD", but following it would be nice nonetheless :)
2. When I assume the number there (400) is meant to be a HTTP status code, it is a wrong one because "internal error" should result in something in the 5xx range.
3. The actual HTTP status code returned is 200 OK.

[metzm]

The reason is that underlying components have been updated, while the openeo GRASS driver at https://openeo.mundialis.de has not been updated.
@m-mohr is it ok if we update the openeo GRASS driver at https://openeo.mundialis.de? The updated version would conform to the openEO API v1.0.

[m-mohr]

Sure, why not? Actually, I'm not exactly sure why you ask me whether it's okay to update your service?! 😅

[metzm]

Asking you because https://openeo.mundialis.de was our reference implementation for the official openEO project and we were not sure, if or for how long we should keep this reference implementation running as is after the end of the project.
Thanks for your answer!

[m-mohr]

Alright, I was not sure and thought you were updating that implementation also for your other projects. Wasn't aware that these are separate. I guess at some point it would be nice to replace the reference implementation with what you use and develop in other projects (e.g. DLR)?! Is that a public interface?

[mmacata]

https://openeo.mundialis.de is updated to latest release. Please try again @christophfriedrich
@m-mohr yes the interface is the same, only underlaying functionality is growing, e.g. we work on exposing all t (time) modules of GRASS GIS as /processes to use them for processing and registering STAC collections via actinia which can then be used as /collections.

[m-mohr]

Okay, good to know. I'm not sure how useful it is to have separate instances running, in principle I think this could be replaced with your new instance.

[metzm]

TODO: Compare implemented error handling with https://api.openeo.org/#tag/EO-Data-Discovery/operation/list-collections