brucecrevensten
commented
2 years ago I thought about this a bit more -- to echo the description above and add a few more notes:
- Rasdaman returns a 404 for the above query, which feels right (and makes our 422 seem like it could be a 404 in this case? But we'd need the code to look at the returned HTTP code from the Rasdaman request and treat it specially),
- The code is returning a 5xx error for some of these endpoints and a 422 in other cases for the identical situation (see #102 I think).
- Structurally the code wraps a try/catch block around the entire "get + process data from the backend" logic and returns a 422 if any exception is thrown. But there could be legit failure modes that aren't identical to our "missing data" situation here: upstream 5xx errors or bugs in the python postprocessing.
It feels like we could/should adjust code to more clearly convey if the upstream errors are 5xx in flavor, or 404/422. I know we're sort of splitting hairs with 422 vs 404 anyhow and I think I keep getting confused about that.
This block of code is returning a 422 error when the backend service Rasdaman is returning 404s for the coverage not containing the particular HUC. This is likely true for the protected areas code also. Here is a URL showing this: http://earthmaps.io:6081/alfresco/flammability/huc/19030103
We may not want a 422 error in this particular case though as the HUC ID is valid, but it just does not have data contained in this coverage on Rasdaman.
Similar to this call to permafrost: http://localhost:5000/permafrost/huc/19030103 which calls: http://zeus.snap.uaf.edu:8080/rasdaman//ows?&SERVICE=WCS&VERSION=2.0.1&REQUEST=GetCoverage&COVERAGEID=iem_gipl_magt_alt_4km&SUBSET=X(-250116.01363577912,-48390.05668846453)&SUBSET=Y(2272600.6033654083,2383776.0085639367)&FORMAT=application/netcdf
Not sure which error code should be returned, but it was suggested we create an issue for discussion.