Renewing tokens inconvenient with offline-first PWAs

[AshleyScirra]

We have an offline-first PWA which loads primary from a Service Worker cache which is kept long-term in between major releases (which could be a few months apart).

It's difficult to update an origin trial token since the old token is kept in the SW cache. When it expires it keeps using the expired token and so disables the feature, even after we renewed it and deployed the updated token to production.

We have an opt-in experiment to use the new Native Filesystem API, and in practice this means users see the feature disappear when our old token expires. These users can resort to flipping the flag, or clearing the cache - which is dangerous since our PWA also allows saving your work to IndexedDB, and if you pick the wrong settings, it'll also wipe all their work from storage. Therefore it seems safer for us to tell users to resort to flipping the flag instead - which then enables it for the whole web.

In particular the Native Filesystem API origin trial appears to be running longer than usual, meaning it appears likely this problem will happen repeatedly during the origin trial.

I'd suggest adding the ability to renew the same token, rather than having to change it.

[jpchase]

It would be a pretty fundamental change to renew existing tokens (more on that below). It seems the quicker path to success is to figure out and address how to get your newly-deployed tokens applied to the cached service worker.

When you deploy a new token, do/could you also update the service worker script? I'm not an expert, but my understanding that any change to the SW script would trigger an update to the service worker, which should include the token. If script changes don't trigger an update, or don't update the token, that sounds like it might be a bug in the Chrome implementation. Otherwise, it's not clear to me if only changing the Origin-Trial header with a new token should trigger an update.

Why would it be hard to renew existing tokens?
For origin trials, one of the key requirements is to allow developers to use a newly-issued token to immediately activate a trial. As well, we wanted origin trials to work even if the browser was offline. That led to making the trial tokens self-contained, so it didn't rely on the browser being able to make a network call to either do a real-time check, or download a list of enabled origins. Also, we wanted web developers to have the flexibility to enable a trial on some pages, but not all, for their origin. Among other things, the expiry date is embedded in the trial token.

[AshleyScirra]

The token is stored in the SW cache, not the SW itself - so I don't think updating the SW script helps. Basically we have an index.html file including the token saved to the SW cache, and opening our web app loads directly from the SW cache without going to network, to ensure it works offline.

I suppose we could modify the index page itself to be served offline first but simultaneously fetch over the network and update the cache if it's received. It seems awkward to have to do this solely for origin trial tokens though, especially since there are other complications, e.g. trying to make sure the index pages for both / and /index.html get updated, since in the eyes of the SW cache those are separate pages.