Develop Reference

Service Worker fails to serve cached resources without at least one reload

I'm trying a simple service worker example modified from MDN.
In main.js I have:
const registerServiceWorker = async () => {
if ("serviceWorker" in navigator) {
try {
const registration = await navigator.serviceWorker.register("./sw.js", {
scope: "./",
});
} catch (error) {
console.error(`Registration failed with ${error}`);
}
}
};
registerServiceWorker();
and in sw.js I have
const CACHE_NAME = "food-journal-v1";
const ASSETS = [
"index.html",
"ReviewDetails.html",
"CreatePage.html",
"static/CoveredByYourGrace-Regular.ttf",
"static/CreatePage.css",
"static/Form.css",
"static/homepage.css",
"static/ReviewDetails.css",
"assets/images/0-star.svg",
"assets/images/1-star.svg",
"assets/images/2-star.svg",
"assets/images/3-star.svg",
"assets/images/4-star.svg",
"assets/images/5-star.svg",
"assets/images/default_plate.png",
"assets/images/delete_icon_for_interface.png",
"assets/images/edit_button_for_interface.png",
"assets/images/Grouppink.png",
"assets/images/home_button_for_interface.png",
"assets/images/favicon.ico",
"assets/images/Logo.png",
"assets/scripts/CreatePage.js",
"assets/scripts/localStorage.js",
"assets/scripts/main.js",
"assets/scripts/ReviewCard.js",
"assets/scripts/ReviewDetails.js",
];
self.addEventListener("install", async () => {
const cache = await caches.open(CACHE_NAME);
await cache.addAll(ASSETS);
});
self.addEventListener("fetch", (event) => {
event.respondWith(caches.open(CACHE_NAME).then((cache) => {
return fetch(event.request).then((fetchedResponse) => {
cache.put(event.request, fetchedResponse.clone());
return fetchedResponse;
}).catch(() => {
return cache.match(event.request);
});
}));
});
Everything seems to be working fine. When I hard refresh the page and inspect the cache, I see that all specified items in ASSETS is populated into cache:
However, if I immediately set my browser to offline mode (ie disable cache, restrict bandwidth to offline) and reload the page, I see that several resources are unable to be fetched by the service worker:
Repeating the same experiment, but this time if I reload the page one extra time just before going offline, the service worker has no issues returning the cached resources. None of the resources on service workers suggests any issue like this should be possible. What might be causing this and how can it be fixed?

After some more digging, I discovered that the promises returned had PromiseResult = undefined which led me to this post which seems to have solved the issue. Why VARY header matching is an issue on only the first page load is still unclear.

Deploy whatsapp-web bot on heroku

I'm creating a whatsapp bot using the node library whatsapp-web.js After I'm done with the script it looks something like (I just put a overview of the orignal script) -
index.js
const {Client, LocalAuth, MessageMedia } = require('whatsapp-web.js');
const qrcode = require('qrcode-terminal');
const client = new Client({
puppeteer: {
args: ['--no-sandbox', "--disable-setuid-sandbox"]
},
authStrategy: new LocalAuth()
});
client.on('qr', (qr) => {
console.log('qr received: ', qr);
qrcode.generate(qr, {small:true});
});
client.on('ready', () => {
console.log('READY');
});
client.on('message', async msg => {
let type = msg.type;
let chat = await msg.getChat();
if(chat.isGroup) {
//do something
}else {
//
if(msg.body === "ping") {
msg.reply("pong");
}
}
});
Everything is fine with the script and it works good on linux or ubuntu (I already added puppeteer build pack on that Heroku app). As I need to run that script continuously I decided to put that on a worker process.
Procfile
worker: node index.js
But now the problem comes in role, how can I authenticate here? I decided to remove that line from index.js
qrcode.generate(qr,{small:true});
And insted I thought I will print all the logs on heroku-cli
heroku logs -a wweb-bot
#my app named as wweb-bot
and from there access the key generated as qr. After that I'll turn it into a qrcode and scan it. When I did all setup and try it I was getting a continuously generating logs of qr keys. It's nonstop, and keep generating keys after every 15-20 sec. What's the problem here? Is it because Heroku has a read only environment or anything else is missing? Please help me how can i do it

remove or comment this code
// authStrategy: new LocalAuth()
it will not work on heroku
but as the code is on server, you don't need to scan again and again, you need to scan only you restart your server
but if you are facing puppeteer error then add these buildpacks in heroku /your project/settings/ scrol down to adduildpack
add these two buildpacks
https://github.com/jontewks/puppeteer-heroku-buildpack
https://github.com/heroku/heroku-buildpack-google-chrome
then redeploy your app

Edit: now whatsapp-web.js added new functionality of doing this called RemoteAuthStatergy just go throughout it.

Blazor - Service worker not installing due to integrity check failure

I'm trying to setup PWA for my blazor application. I followed the instructions on: https://learn.microsoft.com/en-us/aspnet/core/blazor/progressive-web-app?view=aspnetcore-6.0&tabs=visual-studio
But when I open the deployed website the following error occurs:
Failed to find a valid digest in the 'integrity' attribute for resource 'domain/manifest.json' with computed SHA-256 integrity 'uDWnAIEnaz9hFx7aEpJJVS1a+QB/W7fMELDfHWSOFkQ='. The resource has been blocked.
Unknown error occurred while trying to verify integrity.
service-worker.js:22
Uncaught (in promise) TypeError: Failed to fetch
at service-worker.js:22:54
at async onInstall (service-worker.js:22:5)
In the source file this happens here:
async function onInstall(event) {
console.info('Service worker: Install');
// Fetch and cache all matching items from the assets manifest
const assetsRequests = self.assetsManifest.assets
.filter(asset => offlineAssetsInclude.some(pattern => pattern.test(asset.url)))
.filter(asset => !offlineAssetsExclude.some(pattern => pattern.test(asset.url)))
.map(asset => new Request(asset.url, { integrity: asset.hash, cache: 'no-cache' }));
await caches.open(cacheName).then(cache => cache.addAll(assetsRequests));
}
I think the error is happening since the entry in assetsRequests has a wrong hash and the resource is blocked. If I remove the file from the service-worker-assets.js, the service worker installs and the PWA can be used. But I think this is not a reliable solution.
This also happens sometimes for the appsettings.json. In the service-worker-assets.js I can find the following entry:
{
"hash": "sha256-+Py0\/ezc+0k1sm\/aruGPrVhS1jOCTfPKMhOSS+bunek=",
"url": "manifest.json"
},
So the hash does not seem to match. Where does the browser take the wrong hash from? How can I fix this so it does match?
Also it seems that the app is caching older files sometimes. Even when I do a "Reset Cache & Hard Reload" in Chrome the service-worker.js file is still an older version. Any idea how to fix this as well, since it might be related?
Edit: I was also checking this solution: https://stackoverflow.com/a/69935118/11385442. But in the mentioned blazor.boot.json I cannot find any reference to the manifest.json or the appsettings.json. Only Dlls are listed. So the problem only seems to relate to files not listed in blazor.boot.json.
Edit2: What I can see on the webserver is that the following files are published:
appsettings.json
appsettings.json.br
appsettings.json.gzip
So it seems like compressed version are added. Also the appsettings.json has a different size than the one in the solution. My guess is that somewhere in the build or release pipeline (Azure) the files are modified. But even when I copy the appsettings.json manually to the webserver the error still occurs. I was following Information provided here: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-5.0
(Diagnosing integrity problems)

My guess was right. The appsettings.json was modified probably due to the xml transformation in the azure pipeline. My current solution is to exclude integrity validation for such resources as described in the following answer: Error loading appsettings.Production.json due to digest integrity issue
Also I changed the "sw-registrator.js" mentioned in the original posts comments to work correctly, because it didn't load the new files into the cache:
function invokeServiceWorkerUpdateFlow(registration) {
if (confirm("New version available, reload?") == true) {
if (registration.waiting) {
console.info(`Service worker registrator: Post skip_waiting...`);
// let waiting Service Worker know it should became active
registration.waiting.postMessage('SKIP_WAITING')
}
}
}
function checkServiceWorkerUpdate(registration) {
setInterval(() => {
console.info(`Service worker registrator: Checking for update... (scope: ${registration.scope})`);
registration.update();
}, 60 * 1000); // 60000ms -> check each minute
}
// check if the browser supports serviceWorker at all
if ('serviceWorker' in navigator) {
// wait for the page to load
window.addEventListener('load', async () => {
// register the service worker from the file specified
const registration = await navigator.serviceWorker.register('/service-worker.js');
// ensure the case when the updatefound event was missed is also handled
// by re-invoking the prompt when there's a waiting Service Worker
if (registration.waiting) {
invokeServiceWorkerUpdateFlow(registration);
}
// detect Service Worker update available and wait for it to become installed
registration.addEventListener('updatefound', () => {
if (registration.installing) {
// wait until the new Service worker is actually installed (ready to take over)
registration.installing.addEventListener('statechange', () => {
if (registration.waiting) {
// if there's an existing controller (previous Service Worker), show the prompt
if (navigator.serviceWorker.controller) {
invokeServiceWorkerUpdateFlow(registration);
} else {
// otherwise it's the first install, nothing to do
console.log('Service worker registrator: Initialized for the first time.')
}
}
});
}
});
checkServiceWorkerUpdate(registration);
let refreshing = false;
// detect controller change and refresh the page
navigator.serviceWorker.addEventListener('controllerchange', () => {
console.info(`Service worker registrator: Refreshing app... (refreshing: ${refreshing})`);
if (!refreshing) {
window.location.reload();
refreshing = true
}
});
});
}
else
{
console.error(`Service worker registrator: This browser doesn't support service workers.`);
}
Also I had to add this in service-worker.js:
self.addEventListener('message', (event) => {
console.info('Service worker: Message received');
if (event.data === 'SKIP_WAITING') {
// Cause the service worker to update
self.skipWaiting();
}
});
This code was mostly taken from https://whatwebcando.today/articles/handling-service-worker-updates/

Changing the name of a service worker?

I'm trying to figure out what happens if I have a service worker registered on a live site called sw.js and then I rename the service worker to service-worker.js. Now the old one isn't found but it is still showing the old cached version.
How long does it take for it to register the new renamed service worker or how does this work at all?
Edit
This is how I have register the service worker in a react application:
componentDidMount() {
if ("serviceWorker" in navigator) {
navigator.serviceWorker
.register("/service-worker.js")
.then(registration => {
console.log("service worker registration successful: ", registration);
})
.catch(err => {
console.warn("service worker registration failed", err.message);
});
}
}

The newly created service worker (renamed) cannot take over the old one because the old one is still active and controlling the client.
the new service worker(renamed one) will wait until the existing worker is controlling zero clients.
Now imagine a service worker sw.js installed and active (controlling the client),
Chrome will visualize the process for you like this
1. The service worker is registered and active
2. Now let's rename the service worker file to sw2.js
You can see that chrome is telling you that something has changed about the service worker. but the current one will keep controlling the client until you force the new one to take control by clicking on the skipWaitting button or by flushing your cache. clicking on the button will cause the sw2.js to take controll over the sw1.js
Now if you need to do this programmatically, you can do it in the install event inside your service worker by calling self.skipWaiting().
self.addEventListener('install', (e) => {
let cache = caches.open(cacheName).then((c) => {
c.addAll([
// my files
]);
});
self.skipWaiting();
e.waitUntil(cache);
});
The following animated image from Jake Archibald's article The Service Worker Lifecycle can make the idea more clear.

You have to update the instance creation code to reflect this change where your shared worker is being initialized and used, for example your current code would look like
var worker = new SharedWorker("ws.js");
That will need to be updated to
var worker = new SharedWorker("service-worker.js");

I was able to solve it by setting up a server which listens to both /service-worker.js and /sw.js get requests.
Since the service worker was renamed from sw.js to service-worker.js it was not finding the old service worker at http://example.com/sw.js so what I did was the following:
createServer((req, res) => {
const parsedUrl = parse(req.url, true);
const { pathname } = parsedUrl;
// new service worker
if (pathname === "/service-worker.js") {
const filePath = join(__dirname, "..", pathname);
app.serveStatic(req, res, filePath);
// added new endpoint to fetch the new service worker but with the
// old path
} else if (pathname === "/sw.js") {
const filePath = join(__dirname, "..", "/service-worker.js");
app.serveStatic(req, res, filePath);
} else {
handle(req, res, parsedUrl);
}
}).listen(port, err => {
if (err) throw err;
console.log(`> Ready on http://localhost:${port}`);
});
As you can see, I added a second path to serve the same service worker but with the /sw.js endpoint, one for the old sw.js and the other one for the newer service-worker.js.
Now when old visitors that have the old active sw.js will download the newer one and upon revisit, they will automatically fetch the newer renamed service-worker.js service worker.

Updating a ServiceWorker only for new clients

I'm trying to make the update of my ServiceWorker work.
I have an old service worker, some windows are under it's control. Now there is a new version of the ServiceWorker. It get installed properly. But it does not get activated for new pages. My aim is to keep the old one for old pages and the new for every new tab/pages viewed.
Any idea how to accomplish this ?
Edit:
Is how I check that the the new service worker is not updated:
I have a sendMessage method:
sendMessage(message): Promise {
const channel = new MessageChannel();
const p1 = channel.port1;
const result = new Promise(resolve => {
p1.onmessage = ({ data }) => {
resolve(data);
};
});
serviceWorker.controller.postMessage(message, [channel.port2]);
return result;
}
Then I use it to check on page start
this.ready = this.sendMessage('version')
.then(version => {
if (version !== process.env.BUILD_NUMBER) {
console.log('$$ Version mismatch, reinstalling service worker');
throw new Error('build mismatch');
}
return serviceWorker.controller;
});
And I answer in the ServiceWorker
self.addEventListener('message', ({ data, ports }) => {
const client = ports[0];
if (data === 'version') {
client.postMessage(process.env.BUILD_NUMBER);
}
});
Edit
Adding:
event.waitUntil(self.clients.claim());
helps but it activate the ServiceWorker also for old clients.
Thanks

Calling self.skipWaiting() within a service worker's install event handler will cause the newly installed service worker to immediately activate, even if there's an existing, older service worker that's currently active for other clients. Without self.skipWaiting(), the newly installed service worker will remain in a waiting state until all other clients of the previous service worker have been closed.
Calling self.clients.claim() from inside the activate event handler is sometimes used as well, but only if you want the newly activated service worker to take control of already-open clients that are either uncontrolled, or controlled by an older version of the service worker. In your case, it sounds like you do not want that behavior, so you shouldn't call self.clients.claim().