Problems with the service worker + custom domain

Is anyone else having issues with service workers coming from custom domains?

What happened today was pretty strange, but that’s usually normal when dealing with service workers.

I had to update the frontend canister of icpcoins with things that shouldn’t be related to the problem. Once I upgraded the requests towards "api_icpcoins_com were getting blocked by the service worker (These load a list of tokens). They are not hosted on the IC. Is that an intentional restriction? Not being able to fetch anything from the www other than IC?

These worked just fine for a few weeks until now. Perhaps the service worker got changed recently?
For some strange reason, half of my different browsers and computers/phones work and the other half don’t.
And on some the whole page doesn’t load. I’ve tried clearing app data, unregistering service workers, etc, but that doesn’t fix anything. Sometimes checking it out in incognito works, and then after 3 refreshes stops working.
When the page doesn’t load at all I get this errors:

Perhaps a boundary node I am resolving to is lagging. What does the above message mean?

Safari reports this:

I am not sure what to do now. If I point the domain to another place, the service worker installed on all old users is probably going to deny the requests and users will have to manually delete it, which is something 1 out of 1000 will do.

This makes me think, having a global service worker for all, which can suddenly upgrade and break how things work, losing all your users, may not be a good idea. Not sure if that’s happening tho. If there was an update with a breaking change, perhaps custom service workers on the custom domains will be best, or having the option of selecting a specific version.

1 Like

Not really an expert in service workers, but I will pass along to Folks who know much more.

1 Like

Hello @infu. I’m sorry that you’re having these issues with the service worker.

Making calls to is not intentionally restricted, but the problem comes from the service worker trying to resolve ${canisterId} We can get a fix out for this, but in the meantime, is it possible for you to continue using

The error that you’re seeing when the page breaks completely is due to a canary service worker that is in circulation. This canary service worker upgrades the IndexDB version. After upgrading the IndexDB version, on a new request you are hitting a non-canary boundary node and an old service worker gets installed and tries to access the db with an older version and the exception gets thrown.

This canary is being removed from circulation now. If you continue to have the issue, make sure to delete IndexDB’s with your browser’s devtools as well as clear all other local cache etc and then do a hard refresh.

IMPORTANT: If you are experiencing this issue on Internet Identity, make sure that your recovery phrase works before doing this because it might wipe your keys.

1 Like

I haven’t been able to access the NNS or verify myself from any website today using my Internet Identity, getting a similar Failure to Fetch error on Safari. Not sure if it’s related.

Seeing the same issues. Thought I was going crazy.

1 Like

Hello @DHemingway and @Hazel. This is the same issue as above, if you clear all local data in your browser (including IndexDB) and do a hard refresh then this should resolve the issue.
You might need to explicitly delete IndexDB’s, deleting local data might not be enough.

1 Like

@NathanosDev - Just a heads up this is hitting Internet Identity on the original domain as well.

Will give this a shot.

Great, let me know if you have any success. If you’re on Safari mobile too, maybe you could share the steps you take in case it helps others. I don’t have an iPhone to check myself.

Confirmed this works for mobile safari → Clear the history and cookies from Safari on your iPhone, iPad, or iPod touch - Apple Support

I actually didn’t know how to either :slightly_smiling_face:

Clearing everyone on Brave/Chrome appears to have worked too as well :tada:


Awesome, thank you so much for sharing that!

1 Like

Thanks. I saw the fetch proxy code and how it selects subdomains, so I changed it to another domain (nftpkg), but it also threw the same error.

On Chrome/MacOS (normal mode) I can’t seem to get it working still, doesn’t matter what I am deleting. I suppose I am still getting the old service worker. When I switch to incognito, it works.

I will wait for boundary nodes to update. If I remove various IPs from DNS? Will that fix anything? (Using route 53, so I have 4 separate IPs)

On Chrome, after clearing site data are you still getting the exception about the database versions or it’s the issue with the API call?

Hey, today I got it working after clearing app data. Now I am wondering if users who got stuck with it, will have to manually clear app data or if it will resolve automatically for them at some point.

Hey @infu, a fix is out now that should also work for
Users affected by the broken canary on the weekend will need to clear app data to get it working again, but it should be a very small number of people since this canary was live for 16 hours and was serving 5% traffic in 1 out of 4 zones.

1 Like