Overnight Caching is different than some users expect

[rustynwac]

From my tester friend Duncan:
Forecast and map didn't cache overnight. I set airplane mode this morning before opening the app to see what would happen. Obs cached and weather but got this on the forecast page. When I went back on WiFi it loaded, and when I closed the app, disabled WiFi and opened again it cached. So guessing it's due to expiration. I thought that was fixed on the production version and this is a preview bug but maybe not? Either way I'd expect it to be cached with a warning it had expired.

iOS

[kevinherdez]

Interesting, it should work the way he described. We should only get this error when something hasn't been fetched yet. Did he update the app, set it to airplane mode, and then try to open it?

The reason that the Obs and Weather could work in this scenario and not the map view is because we're making 2 new calls to fetch the map layer which wouldn't be cached and then lead to this issue.

[D-McGovern]

I'm certain I updated and opened the newest version of the app last night and it was running as expected. I played around with scrolling to some other center's forecasts on the map, and confirmed with Rusty how to determine what version of the app I'm running.

Then closed it, and was curious about how caching was handled for an expired forecast so flipped to airplane mode before opening the app this morning.

I can try to remember to do this again tomorrow to see if it's a repeatable problem.

[kevinherdez]

Thank you! I'll see if I can repro too with these steps. It could be that one of the new calls isn't caching as expected which is blocking the map from showing

[D-McGovern]

Reproduced again this morning

[kevinherdez]

I was able to reproduce too on both production and the preview version. Great find!

[kevinherdez]

This behavior is actually by design. The decision was made that if we know we need to fetch new data, then we're not going to show the cached data so that everything is ready to go all at once instead of the user seeing multiple re-renders.

// the query we make to the NAC API does not make use of the nominal date for which we're asking, but we want a good
// user experience around the cut-over moment between nominal dates. Consider a user that has loaded this query before
// the cut-over, and has a cached version of the previous day's forecasts. When they refresh their view after the
// cut-over, we want to render only once we've done a fresh load, since we expect to have new data, instead of using
// the cache. By adding the nominal date to the query key, we get this behavior.

[rustynwac]

@D-McGovern what is your user story? The user is heading into the field for a dawn patrol before the fx is published and therefore wants the cached fx from the night before?

@kevinherdez Did you test this with NWAC? NWAC forecasting the night before means I could see this happening quite a bit.

[kevinherdez]

Yup it happens a lot on NWAC. The current fetching pattern is throwing the query away even though it's not expired because the day changed. I can play around with removing the day check so that we always show cached data immediately while we fetch updated data.

I really don't know if it would lead to a bad user experience like the comments are suggesting, but that would be the only con here. Users could potentially see old data on the map for a second before it updates with the current information which could feel weird. However, that seems like a good tradeoff if people are relying on the cache knowing they have good data the night before and then the next day it's gone.

I'm going to move this issues from Map Project to App Season 2025 because it's a current thing that we'll fix outside of the Map Project

[rustynwac]

Interesting. Seems like a miss on first thought but worth exploring a bit more before making changes. I'd be interested to hear if @stevekuznetsov or @yuliadub have any historical context

[stevekuznetsov]

Seems like a difference in the expected flow. Let's hammer out what we expect and make the implementation match.

1. user loads forecast for day N-1
2. user is out of service for long enough such that the forecast is no longer valid
3. user opens the app and opens the page trying to look at the latest forecast, which we know we do not have, instead of the previous forecast

What do we expect the user to see?

The app does not (yet) give the user a way to look at the previous forecast, which is a shame. I don't think there's a great reason for that, other than we just never hammered out what that UX should look like.

My two cents:

• overloading one view to imply that the user is requesting to see the currently-valid forecast, or the most recent cached forecast, depending on what we can show, seems complex
• if we can clearly delineate what forecast the user is intending to ask for, it becomes unambiguous what we show them

I do wonder if we can show a "see previous forecast" button instead on the screenshot above and make the distinction clear. IIRC we use a toast to show an expired forecast, so I don't think I like the outcome of:

• user is on the "show me the latest info" screen, clearly communicating their intent to see the latest forecast
• we keep their scroll position and whatnot
• when they open a day later, if they happen not to catch the "this forecast is expired" toast (or even if it's a banner, and they just scroll past), now it's not obvious that they're looking at an expired forecast