Updates to status entries don't show up unless I refresh the page

[jpmedley]

I noticed this a while ago. I just discovered this has caused someone to create duplicate entries. [https://www.chromestatus.com/features#unload h](https://www.chromestatus.com/features#unload h)

[ebidel]

For perf, there are a few extra layers of caching now that didn't exist before. When updating/adding/removing a feature, the list may not reflect it right away.

features.json is now being cached by the browser (http caching) and service worker. The latter will choose network first, but the former will keep the file around for 10min. https://github.com/GoogleChrome/chromium-dashboard/blob/master/settings.py#L34

[johnmellor]

I hit this two. I ended up creating 3 entries for "Notification image" since the new ones weren't showing up:
https://www.chromestatus.com/features/5753747552600064
https://www.chromestatus.com/features/5190797599178752
https://www.chromestatus.com/features/5645583096217600

Navigating to the dashboard homepage was not enough, and I think even explicitly refreshing the page didn't help - I had to use Shift+F5 to refresh bypassing service worker.

Compounding this issue, there also seems to be no way to delete an entry.

[ebidel]

I've removed the dupes.

When you create a feature, would a message like "Feature created. It may take a few moments to show up on the dashboard" be sufficient"? I want to strict the right balance of having the added caching for users vs. annoying/confusing contributors. The majority of users will benefit for the caching.

[johnmellor]

Could adding (or editing) a feature invalidate the local cache, so at least the author sees it straight away?

It would also be nice if refreshing the page without pressing Shift was sufficient to see updated information. FetchEvent.isReload gives you that information, but is apparently going away and being replaced with FetchEvent.request.cache.

@jakearchibald, what's the best practice for making (non-Shift) reloads work?

[ebidel]

The endpoint features.json is requested, network first by the service worker. So it should always be the latest stuff. I think the issue here is that we added browser/http caching to that endpoint as well for browsers that don't support sw). So the when you refresh the page, you'll still get the browser's cached copy for 10min.

/features.json is becoming a fairly hefty response as more features are added to the dashboard. Keeping http caching on the endpoint would be my preference.

After creating a feature, what if we redirected to the individual page (e.g. https://www.chromestatus.com/feature/5687338902487040) rather than the /features list? That would give you immediate results and would help prevent dupes.

[johnmellor]

Redirecting to the individual page wouldn't work, because that feature isn't found in features.json, so it would just displays the homepage list anyway (that's what happens today if you explicitly visit the link).

I think the key is to invalidate the cache when it is changed locally, or when the user reloaded the page. It seems this can be done by setting request.cache to 'no-cache' when you fetch features.json, if it has been invalidated.

[ebidel]

Not sure I completely follow. https://www.chromestatus.com/feature/5687338902487040 is served with no-cache and doesn't rely on features.json. If we redirected you that page after you've created the feature, it would at least let the creator know the entry was saved. My thinking is that that would alleviate the uncertainty on whether the feature was created or not.

But yea, the feature wouldn't show up on the list (chromestatus.com/features) until features.json was invalidated. Using fetch() {cache: no-cache} is probably the way to go. We'll have to come up with a scheme to know you've been redirected from an edit page. Should be doable.

We support it right? I see FF is just now adding it: https://hacks.mozilla.org/2016/03/referrer-and-cache-control-apis-for-fetch/

[johnmellor]

Oh, maybe https://www.chromestatus.com/feature/5687338902487040 would work. I was thinking of the very similar URL https://www.chromestatus.com/features/5687338902487040 (with an s after /feature), which does rely on features.json since it shows the feature inline in the list of features (the later is the link included in the generated intent to implement email, for good or for bad).

[RByers]

I think there must be something else going on here - in #397 we saw this happening in Chrome where the SW should be working fine. Adding a new feature should be rare enough that invalidating or even force re-fetching any possibly stale resources shouldn't really be a problem.

[ebidel]

#397 seems like a dupe of this.

[ebidel]

To add to the confusion, this isn't happening for me. I just added two new features and they showed up right away on https://www.chromestatus.com/features.

In that profile I see no-cache on the response:

However, in another profile, I see public caching:

....and in an incognito window, I see the public caching on that same profile.

Since features.json is requested by the sw using networkFirst, maybe this inconsistency is part of the problem. No idea why the differences.

[ebidel]

I think #399 will help address this issue

[ebidel]

Deployed. Let's see if it helps.