Ben Kelly [:bkelly, not reviewing] Reporter
	Description • 6 years ago

Recently I've been running into a weird situation on https://pinafore.social.  It has logic that triggers a toast message saying "update available" when the updatefound event is fired.  It seems to fire a few times a day for me on firefox.

I've been trying to figure out how firefox could be sending too many updatefound events.  This morning I was poking around my profile directory and found that the Cache API sqlite database for the site was open.  It had a -shm file and local sqlite3 access could not read the database.  I did not have any pinafore tabs or service workers running.

This could potentially trigger an updatefound event if the script cache fails to open the Cache API (because the database is locked as per the sqlite3 thing above).  Indeed, upon first open of pinafore this morning it told me there was an update, but there was no new version posted online.

Its a bit mysterious to me what is going on here.  I'm not sure how we could be leaving the Cache API open for so long.  We need to investigate more.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 1 • 6 years ago

Maybe more significant than the -shm file is that the cache had a -wal file.  The context_open.marker file was also there.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 2 • 6 years ago

One thing I've noticed is we leave Cache API open while a window is in the bfcache.  I haven't produced a problem from that, but in theory we may not want to do that for perf reasons.  I'm not sure we have a good way for Cache API to shut itself down while in bfcache, though.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 3 • 6 years ago

I just got the extraneous updatefound and the cache API was not open.  So that is not it.

It seems like it might be somewhat time based.

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 4 • 6 years ago

The pinafore server is doing something that prevents us from doing a 304 revalidation of the script, although we should still get a normal 200.  Its max-age also is 10 minutes.  I wonder if this corresponds to the timing I'm seeing.

HTTP/2.0 200 OK
date: Thu, 26 Apr 2018 00:33:01 GMT
content-type: application/javascript; charset=utf-8
content-security-policy: script-src 'self' 'sha256-0MCgHAFNUG4VRZg8Hh2LgrBtmMzg4KnM+3wJ/vRlpV8='; worker-src 'self'; style-src 'self' 'unsafe-inline'; frame-src 'none'; object-src 'none'; manifest-src 'self'
x-dns-prefetch-control: off
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=15552000; includeSubDomains
x-download-options: noopen
x-content-type-options: nosniff
referrer-policy: no-referrer
x-xss-protection: 1; mode=block
cache-control: public,max-age=600
etag: "4379-QEFVfxAf2TcfDRTmFh7xJ9FlYJc"
vary: Accept-Encoding
content-encoding: br
x-now-trace: sfo1
server: now
x-now-id: mtg26-1524702781714-HGhLXeWJ799uPWDA7hR0z31o
x-now-instance: 865814630
X-Firefox-Spdy: h2

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 5 • 6 years ago

I think this might be a pinafore issue now.  I saw a timestamp change in the service worker script text over night.  Investigating further as it happens.

Also see:

https://github.com/nolanlawson/pinafore/issues/80

	Ben Kelly [:bkelly, not reviewing] Reporter
	Comment 6 • 6 years ago

Nolan and I determined this is a site bug.