Gatsby: Netlify redirects are broken seemingly randomly

Created on 30 Oct 2018  路  11Comments  路  Source: gatsbyjs/gatsby

Description

Redirects don't work consistently, one build results in them not working at all (which seems to be the one right now), another in them not working just on the index page. Here's the code that's used: https://github.com/xsolve-pl/boldare-tech/blob/master/gatsby-node.js#L40 I'm wondering if that's even supposed to work without the trailing slash, but adding a rule that considers that resulted in redirects not working at all several times.

Steps to reproduce

Enter https://tech.xsolve.software/ and you should be redirected to new domain, but you're not. Same for other pages if you click on anything. Interestingly, right now only combined with the other redirect, so https://tech.xsolve.software/a, it works.

Expected result

https://tech.xsolve.software/ should redirect to https://tech.boldare.com/ Same for other pages.

Actual result

Either 404s are thrown in the console or the index site isn't redirected.

Environment

System: OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver) CPU: x64 Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz Shell: 4.4.19 - /bin/bash Binaries: Node: 9.10.1 - /usr/local/bin/node Yarn: 1.10.1 - /usr/bin/yarn Browsers: Chrome: 70.0.3538.77 Firefox: 63.0 npmPackages: gatsby: ^2.0.17 => 2.0.17 gatsby-image: ^2.0.13 => 2.0.13 gatsby-plugin-algolia: ^0.2.0 => 0.2.0 gatsby-plugin-catch-links: ^2.0.3 => 2.0.3 gatsby-plugin-favicon: ^3.1.4 => 3.1.4 gatsby-plugin-feed: ^2.0.7 => 2.0.7 gatsby-plugin-google-analytics: ^2.0.6 => 2.0.6 gatsby-plugin-manifest: ^2.0.4 => 2.0.4 gatsby-plugin-netlify: ^2.0.2 => 2.0.2 gatsby-plugin-netlify-cms: ^3.0.4 => 3.0.4 gatsby-plugin-offline: ^2.0.5 => 2.0.5 gatsby-plugin-react-helmet: ^3.0.0 => 3.0.0 gatsby-plugin-react-svg: ^2.0.0 => 2.0.0 gatsby-plugin-sharp: ^2.0.5 => 2.0.5 gatsby-plugin-sitemap: ^2.0.1 => 2.0.1 gatsby-remark-copy-linked-files: ^2.0.5 => 2.0.5 gatsby-remark-external-links: ^0.0.4 => 0.0.4 gatsby-remark-images: ^2.0.3 => 2.0.3 gatsby-remark-prismjs: ^3.0.1 => 3.0.1 gatsby-remark-responsive-iframe: ^2.0.5 => 2.0.5 gatsby-remark-smartypants: ^2.0.5 => 2.0.5 gatsby-source-filesystem: ^2.0.1 => 2.0.1 gatsby-transformer-remark: ^2.1.6 => 2.1.6 gatsby-transformer-sharp: ^2.1.3 => 2.1.3
but the problem itself exists only on production on Netlify.

question or discussion

Most helpful comment

It seems to work now, thanks.

All 11 comments

I'm also quite sure it only or mostly affects people who visited the site on the old domain before (could anyone confirm?) - since in incognito it seems fine. But clearing cache and cookies doesn't really help and I need a solution that will work for old visitors without them doing anything.

EDIT: I think it's related to service worker because also unregistering that helped. Can I tell the browser to unregister it for that subdomain somehow?

@Destroy666x so just in clicking that link it _does_ work?

https://tech.xsolve.software -> https://tech.boldare.com
https://tech.xsolve.software/.net-in-my-browser/ -> https://tech.boldare.com/.net-in-my-browser/

What am I missing here?

@DSchau as I mentioned above it seems to only affect people that had a service worker registered on the old domain. Shouldn't Gatsby automatically unregister it when domain redirection exists?

as I mentioned above

That was in an edit so I didn't catch it! (had the page open)

Shouldn't Gatsby automatically unregister it when domain redirection exists?

We definitely don't do this. Rather than throwing Gatsby into the mix here, maybe just deploy a Netlify redirects file to that domain since it's being redirected entirely anyways?

That's exactly what Gatsby Netlify plugin generates with createRedirect in https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-netlify/src/create-redirects.js, but it doesn't solve the issue of persisted service worker causing 404 redirect issues.

@Destroy666x what about creating static/sw.js (will probably need to disable gatsby-plugin-offline as well), registering that in your head/script tags, and unregistering the service workers in that file?

That _should_ wipe out any subscriptions and then the redirects would work as you'd expect.

Also cc @davidbailey00 you have any ideas here?

Hey @Destroy666x, unfortunately it's not so simple to automatically remove service workers due to the way that they persist in the browser - I think what @DSchau said should work best, which means that you might have to run Gatsby again on the old site without the redirects (perhaps you could temporarily use client-side redirects?)

Having said that, with the way that our offline plugin works (at least with the latest version) it should have detected missing Gatsby resources, but a non-404 response by loading the URL directly, which should have caused it to redirect to the new site after all - to get some idea of what's going on, do you still have Gatsby resources present on the old website? If so it might be best just to upload an empty site with only the redirects, since the offline plugin might figure out what's going on and redirect properly.

I'm not sure I understand your 2nd paragraph - it's a single Netlify server with the same resources including a redirection. How would I empty the website without disturbing the production on the new domain?

As for a script unregistering, thank, I'll try adding that, but shame that the framework can't/doesn't handle it properly itself.

How would I empty the website without disturbing the production on the new domain?

Before doing anything else, please can you try updating your plugins for the website on the old domain? You're using old versions of packages, including the offline plugin at 2.0.5 (latest is 2.0.10). Recent changes have been made which should cause the offline plugin to handle things like redirects properly.

If this doesn't work, let me know and I'll see if I can help with unregistering the SW manually.

shame that the framework can't/doesn't handle it properly itself.

Unfortunately Gatsby can't automatically figure out when you want to unregister an SW, so we don't try to handle this. Having said that, perhaps in the future we could create a plugin to help with unregistering SWs, but it still wouldn't be possible to figure out when to do this automatically (not everyone using redirects wants to do this so we can't make any assumptions).

Sure, I'll try upgrading the offline plugin and will let you know if the problem disappears.

It seems to work now, thanks.

Was this page helpful?
0 / 5 - 0 ratings