Surface login/service availability errors immediately to the user if they happen about icepyx

[JessicaS11]

@fperez I suspect you're right. It sounds like the solution is better response handling/testing for a proper session after icepyx tries to log the user in. Is that something you could take on? It should fit well within the Earthdata class functionality.

[fperez]

Thanks @JessicaS11! Yes, I'm happy to take a look at that code later on :) Unfortunately today my time for the hack week is winding down, I have to switch gears in 15 min.. But I'll tag this one for later and we can see if it can be made more robust.

[fperez]

We'll need to experiment with exactly when these error codes come from NSIDC - I'm not an expert web person at all. Some input from perhaps folks on the NSIDC/EarthData side would help a lot, in terms of knowing when/which error codes can come from their end. It seems to me that what we need to do is, if a login is successful (which evidently can happen even when the service is down), learn exactly which error info can come back and check for those. We can then immediately surface such errors appropriately to the user...

[JessicaS11]

@asteiker @nicholas-kotlinski @wallinb Can one of you provide any of this information from the NSIDC side?

[nicholas-kotlinski]

It seems as though a 503 would not be generated from, or delivered by, NSIDC proper - but that the error is passed along from dependent upstream systems like EDSC or CMR. Based on some sleuthing by Amy FitzGerrell at NSIDC, it seems this most often happens during preventative maintenance on their end. When the error occurs outside of planned preventative maintenance, it’s not possible to predict it. The fix for the issue would be to have icepyx do a better job of surfacing the error, somehow, so that it isn’t buried.

HTTP Status Code 503 – Internal error because a service dependency is not available

Search HTTP Status Code 503 here for a short description: https://cmr.earthdata.nasa.gov/search/site/docs/search/api.html

[asteiker]

A few additional points: This error may be caused by either CMR or Earthdata Login. Earthdata Search Client (which we refer to internally across EOSDIS as "EDSC") isn't involved in our API response (though it also queries the NSIDC API just like icepyx or any other application or client). Both the CMR and Earthdata Login rarely have planned maintenance in their production environment so usually this will be caused by an ephemeral unplanned issue. Thanks Nic for tracking this down with Amy F. further!

[JessicaS11]

In digging into #166, I just started a branch surf_err that completes the first step of this issue (surfaces errors returned during the granules.get_avail() search step of Query). It'd be great if @facusapienza21 or @fperez could begin expanding this to other areas of API interaction to move this issue along.

[JessicaS11]

While debugging another user issue (which resulted from no subset data messages no longer being surfaced as an error), I added on to this branch to re-catch the no subset data orders and let the user know they can't be downloaded (in case they miss the order message). @facusapienza21 @fperez @nicholas-kotlinski @wallinb - if you have a few minutes to review #195 it would be greatly appreciated!