Old weather data fetched

[zwei2016]

Hi - It seems I have the old data problem recently. I wrote a python script to fetch weather forecast data once every 2 hours, and received the old weather data about 2 days ago. Please check my log file as below. After two weather info about July 12, the server provided the data of July 10. I think maybe something related to the number after the http code 200, what do they mean (3579 and 3647)?

"Data timestamps" is the weather information updating time in the retrieved data.

DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.weather.gov:443
DEBUG:urllib3.connectionpool:https://api.weather.gov:443 "GET /gridpoints/BOX/69,76/forecast/hourly HTTP/1.1" 200 3579
INFO:root:Get the next 2 days data
INFO:root:Got the infomation
INFO:root:[datetime.datetime(2021, 7, 12, 11, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000))), datetime.datetime(2021, 7, 12, 12, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000)))]
INFO:root:Data timestamps is 2021-07-12T13:49:58+00:00.
INFO:root:NOAA info received, update again in 2 hours

DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.weather.gov:443
DEBUG:urllib3.connectionpool:https://api.weather.gov:443 "GET /gridpoints/BOX/69,76/forecast/hourly HTTP/1.1" 200 3579
INFO:root:Get the next 2 days data
INFO:root:Got the infomation
INFO:root:[datetime.datetime(2021, 7, 12, 11, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000))), datetime.datetime(2021, 7, 12, 12, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000)))]
INFO:root:Data timestamps is 2021-07-12T13:49:58+00:00.
INFO:root:NOAA info received, update again in 2 hours

DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.weather.gov:443
DEBUG:urllib3.connectionpool:https://api.weather.gov:443 "GET /gridpoints/BOX/69,76/forecast/hourly HTTP/1.1" 200 3647
INFO:root:Get the next 2 days data
INFO:root:Got the infomation
INFO:root:[datetime.datetime(2021, 7, 10, 19, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000))), datetime.datetime(2021, 7, 10, 20, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000)))]
INFO:root:Data timestamps is 2021-07-10T19:43:11+00:00.
INFO:root:NOAA info received, update again in 2 hours

DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.weather.gov:443
DEBUG:urllib3.connectionpool:https://api.weather.gov:443 "GET /gridpoints/BOX/69,76/forecast/hourly HTTP/1.1" 200 3647
INFO:root:Get the next 2 days data
INFO:root:Got the infomation
INFO:root:[datetime.datetime(2021, 7, 10, 19, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000))), datetime.datetime(2021, 7, 10, 20, 0, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=72000)))]
INFO:root:Data timestamps is 2021-07-10T19:43:11+00:00.
INFO:root:NOAA info received, update again in 2 hours 

[jeff-bryant]

I'm seeing something similar, although in my case this is from C# code.
In my case when I use the this url from the browser:
https://api.weather.gov/gridpoints/HNX/51,100/forecast
I see the forecast for the next 7 days.
When i use the exact same url from within my application I'm getting data starting from the beginning of the current week. This leads me to believe there may be a header that I'm missing in the request.

I am adding a User-Agent header, is there another header that is required? Think I'll have to dig around some more.

[michaelstringer]

Exactly! Same! I can use Postman to fetch current data from the gridpoints URL (https://api.weather.gov/gridpoints/MFR/107,60/forecast in our case) all day long, but try and fetch using my web application? It's usually days to up to a week old. Frustrating!

[scadergit]

The number after the status code is the content length, and not very relevant, although it does hint at the actual problem, which is a known issue. The fix requires replacing a web service that randomly provides invalid response. That response gets cached by our CDN, which is why requests from postman can vary from your application, as it is likely hitting a different CDN cache pool. You can verify this by looking at the correlation id in the response header. A new one is assigned every time a request reaches an origin server.

The effort to replace this service has finally made it to the top and should be resolved later this year (giving time to get though testing and the NCO deployment process).

[jeff-bryant]

Thanks for the update. I was getting irritated at my code, trying all kinds of different contortions to get it to work. I'll put the piece of code on hold for the time being, it's not critical to the app. I may hook in an API from another vendor but I'd like to see this one ultimately working.

[katilley]

I think I'm seeing the same issue. Getting old data sometimes, correct data other times.

Is there a way to verify this is the same issue?

Here is the response header for a case where old data was sent...

{x-edge-request-id: fcec9b79, connection: keep-alive, last-modified: Sun, 08 Aug 2021 21:00:00 GMT, cache-control: public, max-age=236, s-maxage=3600, access-control-allow-origin: *, date: Fri, 06 Aug 2021 20:25:42 GMT, vary: Accept-Encoding,Accept,Feature-Flags,Accept-Language, content-encoding: gzip, strict-transport-security: max-age=31536000 ; includeSubDomains ; preload, x-correlation-id: c9577a7, content-type: application/geo+json, server: nginx/1.16.1, x-request-id: f06e7f92-a4c1-4941-aabc-510e92f1e0d3, x-server-id: vm-bldr-nids-apiapp8.ncep.noaa.gov, access-control-allow-headers: Feature-Flags, content-length: 3454, expires: Fri, 06 Aug 2021 20:29:38 GMT}

[StephenClouse]

It is. You may notice that the Last-Modified date is in the future, which is obviously wrong. This is the faulty data from the backend manifesting at the front end.

We had truly expected to have this fully fixed by now, but as the great philosopher Jagger once said, "you can't always get what you want". I'm going to see if there are any stopgap measures we can do in the meantime.

For the moment, if you are able to implement this in your client, if you see a future Last-Modified date, treat it as an error.

[sean-user]

@scadergit @StephenClouse Do you guys have an update as to when this problem will be fixed?

[cc8080]

I'm seeing old data returned as well. Please see below for an example from yesterday. The requests from the Android app I'm developing received partially out of date data. I didn't see a future last-modified date, but rather the forecast period was showing that it was daytime when a fetch using a browser showed (correctly) that it was night. The correlation ID and server ID are different, so the responses are coming from different places.

Is there a reasonably reliable workaround? This is a critical issue for a weather app.

Thanks!

Summary:

Forecast URL: https://api.weather.gov/gridpoints/MFR/110,28/forecast
 
 App gets:
 
 updated: 2021-09-14T21:28:11+00:00 
 "periods": [
      {
        "number": 1,
        "name": "This Afternoon",
        "startTime": "2021-09-14T14:00:00-07:00",
        "endTime": "2021-09-14T18:00:00-07:00",
        "isDaytime": true,
   etc.
 
Browser gets:
 "updated": "2021-09-14T21:28:11+00:00"
 "periods": [
	{
		"number": 1,
		"name": "Tonight",
		"startTime": "2021-09-14T21:00:00-07:00",
		"endTime": "2021-09-15T06:00:00-07:00",
		"isDaytime": false,
  etc.

Headers:

Browser response Headers:

access-control-allow-headers: Feature-Flags
access-control-allow-origin: *
cache-control: public, max-age=876, s-maxage=3600
content-encoding: gzip
content-length: 1535
content-type: application/geo+json
date: Wed, 15 Sep 2021 05:27:28 GMT
expires: Wed, 15 Sep 2021 05:42:04 GMT
last-modified: Tue, 14 Sep 2021 21:28:11 GMT
server: nginx/1.16.1
strict-transport-security: max-age=31536000 ; includeSubDomains ; preload
vary: Accept-Encoding
vary: Accept,Feature-Flags,Accept-Language
x-correlation-id: 32e8f5d8
x-edge-request-id: 38a7666d
x-request-id: 2678b338-6e89-4736-8a63-1b0a240bf848
x-server-id: vm-lnx-nids-apiapp6.ncep.noaa.gov

Application:

Request headers:

Accept-Encoding: gzip
Connection: Keep-Alive
Host: api.weather.gov
User-Agent: okhttp/3.14.9

Response headers:
		
access-control-allow-headers: Feature-Flags
access-control-allow-origin: *
cache-control: public, max-age=472, s-maxage=3600
content-encoding: gzip
content-length: 1520
content-type: application/geo+json
date: Wed, 15 Sep 2021 05:13:03 GMT
expires: Wed, 15 Sep 2021 05:20:55 GMT
last-modified: Tue, 14 Sep 2021 21:28:11 GMT
server: nginx/1.16.1
strict-transport-security: max-age=31536000 ; includeSubDomains ; preload
vary: Accept-Encoding; Accept,Feature-Flags,Accept-Language
x-correlation-id: 4b15ea36
x-edge-request-id: 7151d1ff
x-request-id: c6de5147-c3be-4478-b062-747f521638f8
x-server-id: vm-lnx-nids-apiapp3.ncep.noaa.gov

[cc8080]

Today, I was seeing the "last-modified in the future" as well as stale data. Eventually I tried adding "Cache-Control: must-revalidate" to the request headers and magically I got a current forecast. I can only hope it wasn't a coincidence.

[cc8080]

Still getting invalid data despite the new request headers. Back to DWML for me.

[scadergit]

This known bug in the forecast endpoint has not been resolved yet, so using forecast application data remains the most reliable for now.

[cc8080]

Thanks for clarifying that. Can you please share a pointer to the most current documentation? I want to be sure I'm using the latest & greatest. Thanks!

[scadergit]

There is no documentation for the forecast application data, but the API is found at https://www.weather.gov/documentation/services-web-api.

[BlBoyer]

Hopefully this will help someone:
I experienced the same issue (retrieving old data while fetching forecast data), getting it 2-3 days before in some cases. So, in order to byass the old data, I used a date object and iterate through the periods 'startTime' variable to access the correct period data. Oddly enough, after doing this, the forecast 'updated' times have been close to current times since altering my code- which is performed after the fetch. Obviously, this isn't an actual solution to whatever is going on, but it appears to have fixed my issue.

[BillMoody]

Hi Am am trying to teach some kids to to program and I thought I'd use this API as an example. I am also getting the strange behavior. The data will not update even from different machines. The last update, header, is a year into the future. Are there any specific headers I should send other than the user-agent?
Thanks

Status: 200
AsOf: 2021-12-31T11:18:10+00:00
Headers: {'Server': 'nginx/1.20.1', 'Content-Type': 'application/geo+json', 'Last-Modified': 'Sat, 31 Dec 2022 11:18:10 GMT', 'Access-Control-Allow-Origin': '*', 'Access-Control-Expose-Headers': 'X-Correlation-Id, X-Request-Id, X-Server-Id', 'X-Request-ID': '11d78796-5bbd-45c2-a556-0e03ae659996', 'X-Correlation-ID': '2780c9e5', 'X-Server-ID': 'vm-bldr-nids-apiapp10.ncep.noaa.gov', 'Content-Encoding': 'gzip', 'Content-Length': '1703', 'Cache-Control': 'public, max-age=771, s-maxage=3600', 'Expires': 'Sat, 01 Jan 2022 21:45:08 GMT', 'Date': 'Sat, 01 Jan 2022 21:32:17 GMT', 'Connection': 'keep-alive', 'Vary': 'Accept-Encoding, Accept,Feature-Flags,Accept-Language', 'X-Edge-Request-ID': '8ea3cb3', 'Strict-Transport-Security': 'max-age=31536000 ; includeSubDomains ; preload'}

[linuxha]

Yes, I did. JAH007's response below contains a temporary workable solution (use preview-api.weather.gov until the code has be accepted). But I recommend reading at least the bottom of the thread.

[StephenClouse]

Did you vary the "123" to some other value on each and every call? I use a random number generator (0-32767) in that field, so it's different with each request. The trick seems to work when the value is changing and not always the same.

Please don't do this.

[sean-user]

@StephenClouse Why not?

[StephenClouse]

@sean-user Cache busting like this just forces more load on our production systems and they have enough to do already.

[sean-user]

Okay, thanks. Understood.

[jah1007]

As mentioned in #492 we are testing out a change to the caching on our pre-production site which should provide more reliable forecast data.