?onfail=cache says there's no results, even though I was getting new results recently. about avwx-api

[devdupont]

I found a bug where the second call to the cache was not forcing the data to be returned. I've refactored the code to force the cache to return on the first call and keep it in memory during handling removing the second call. The fix has been pushed. I've also changed the default onfail value to "cache"

[devdupont]

I’ve noticed that the NOAA servers have been unpredictable lately. However, the cache option should still return data if available. I need to check if there’s a TTL on the cache table.

As for the NOAA issue, there’s not much I can do if their servers go down, but I can add more regional data sources to lessen the load on NOAA. Is there a best source for UAE airports?

[Lugghawk]

I'm not sure unfortunately, we've only been using AVWX for these and not any other services.

I'm not too worried about issues with the source, I understand there's not much you can do on your end about them. I just wanted to bring the onfail issue up since it doesn't behave as expected.

[Lugghawk]

So I checked out the code here: https://github.com/avwx-rest/AVWX-API/blob/3c58312abe7175793f32c3dff1a3be469e298da7/avwx_api/handle/metar.py#L62 for the METAR handling which I'm using.

It looks like the initial lookup is done via the cache too (Line 75). I'm not sure if the nofail=cache makes sense in this context then, since if the initial check doesn't give you a valid return then we would not expect one the next time we check the cache. If anything appears in between the first and second calls, then it would be new data.

I'm not sure what to suggest to improve this. It's not clear from this block of code (and I'm not great at python) where the cache is being set from, but the second cache lookup on line 84 when nofail is specified seems redundant and won't actually come up with the older data.