Gatsby-WordPress site only loads on a fresh browser session & immediately fails on any successive visit

avinoamsn · June 17, 2021, 12:00am

The site in question: allianceforpatientaccess.org
The Netlify URL (redirects to the primary domain): afpa.netlify.app

Brief

My Gatsby-WordPress site is suffering from some sort of caching issue, but I’m struggling to determine the cause (or a solution).

The initial load appears to work correctly with a fresh browser session (e.g. following a hard refresh, or in incognito mode), but immediately fails (<8ms) with the generic net::ERR_FAILED on any successive visit.

Details

The issue was first reported on June 10th. The Gatsby site is rebuilt every time new content is published to the WordPress instance, which happens a few times a day. Looking at the logs from around June 10th doesn’t reveal anything out of the ordinary, but I’ve included the log for the last build before the first error reports below. (There are a few warnings & errors within it, but none that stick out as relating to this issue.)

Thoughts

I’ve been unable to repro this error in my local environment, so I’m guessing that it has something to do with either the site/domain config (could this possibly be related to DNS or SSL?), or the interaction b/w Netlify & Gatsby. My last update to the Gatsby site was almost a week before the first bug reports (details in Attempted Fixes below), so it doesn’t seem like this issue is the result of code changes. I could also see this being a trivial matter, and that I’m only having difficulty due to a lack of conceptual knowledge somewhere - but this behavior seems pretty pequliar to me.

If there’s any other info that I could provide that is relevant to the matter, please let me know!

Attempted Fixes

I initially tried the Clear cache and deploy site operation in Netlify, which made no difference.
My last update to the Gatsby site was adding LogRocket & LogRocketReact on June 5th. The timeline doesn’t quite line up with the code changes, but even so I rolled this back - to no avail.
I also tried disabling Gatsby’s service worker (gatsby-plugin-offline). Given how quickly the network request fails (<8ms) I thought there may be some conflict with the downloaded website. This also had no discernible effect.

Build log - Jun 9 at 4:17

4:17:26 PM: Build ready to start
4:17:28 PM: build-image version: 0582042f4fc261adc7bd8333f34884959c577302
4:17:28 PM: build-image tag: v3.7.6
4:17:28 PM: buildbot version: 0e3c0977102e4a2f70b6394a3004ef3b079e9861
4:17:28 PM: Fetching cached dependencies
4:17:28 PM: Starting to download cache of 467.4MB
4:17:31 PM: Finished downloading cache in 3.437058609s
4:17:31 PM: Starting to extract cache
4:17:47 PM: Finished extracting cache in 15.713240462s
4:17:47 PM: Finished fetching cache in 19.293481656s
4:17:47 PM: Starting to prepare the repo for build
4:17:47 PM: Preparing Git Reference refs/heads/master
4:17:48 PM: Parsing package.json dependencies
4:17:49 PM: Starting build script
4:17:49 PM: Installing dependencies
4:17:49 PM: Python version set to 2.7
4:17:49 PM: Started restoring cached node version
4:17:54 PM: Finished restoring cached node version
4:17:55 PM: v10.24.1 is already installed.
4:17:56 PM: Now using node v10.24.1 (npm v6.14.12)
4:17:56 PM: Started restoring cached build plugins
4:17:56 PM: Finished restoring cached build plugins
4:17:56 PM: Attempting ruby version 2.6.2, read from environment
4:17:58 PM: Using ruby version 2.6.2
4:17:58 PM: Using PHP version 5.6
4:17:58 PM: Started restoring cached node modules
4:17:58 PM: Finished restoring cached node modules
4:17:58 PM: Started restoring cached go cache
4:18:00 PM: Finished restoring cached go cache
4:18:00 PM: Installing Go version 1.12
4:18:00 PM: unset GOOS;
4:18:00 PM: unset GOARCH;
4:18:00 PM: export GOROOT='/opt/buildhome/.gimme_cache/versions/go1.12.linux.amd64';
4:18:00 PM: export PATH="/opt/buildhome/.gimme_cache/versions/go1.12.linux.amd64/bin:${PATH}";
4:18:00 PM: go version >&2;
4:18:00 PM: export GIMME_ENV='/opt/buildhome/.gimme_cache/env/go1.12.linux.amd64.env';
4:18:00 PM: go version go1.12 linux/amd64
4:18:00 PM: Installing missing commands
4:18:00 PM: Verify run directory
4:18:00 PM: 
4:18:00 PM: ────────────────────────────────────────────────────────────────
4:18:00 PM:   Netlify Build                                                 
4:18:00 PM: ────────────────────────────────────────────────────────────────
4:18:00 PM: 
4:18:00 PM: ❯ Version
4:18:00 PM:   @netlify/build 11.37.0
4:18:00 PM: 
4:18:00 PM: ❯ Flags
4:18:00 PM:   deployId: 60c121d58f68f72a521b7ed2
4:18:00 PM: 
4:18:00 PM: ❯ Current directory
4:18:00 PM:   /opt/build/repo
4:18:00 PM: 
4:18:00 PM: ❯ Config file
4:18:00 PM:   /opt/build/repo/netlify.toml
4:18:00 PM: 
4:18:00 PM: ❯ Context
4:18:00 PM:   production
4:18:00 PM: 
4:18:00 PM: ────────────────────────────────────────────────────────────────
4:18:00 PM:   1. Build command from Netlify app                             
4:18:00 PM: ────────────────────────────────────────────────────────────────
4:18:00 PM: 
4:18:00 PM: $ npm run build
4:18:01 PM: > afpa-wordpress@1.0.0 build /opt/build/repo
4:18:01 PM: > run-p build:gatsby build:lambda
4:18:01 PM: > afpa-wordpress@1.0.0 build:gatsby /opt/build/repo
4:18:01 PM: > gatsby build
4:18:01 PM: > afpa-wordpress@1.0.0 build:lambda /opt/build/repo
4:18:01 PM: > netlify-lambda build src/lambda
4:18:02 PM: netlify-lambda: Building functions
4:18:03 PM: Hash: b8f26f1732209796f315
4:18:03 PM: Version: webpack 4.46.0
4:18:03 PM: Time: 750ms
4:18:03 PM: Built at: 06/09/2021 8:18:03 PM
4:18:03 PM:         Asset      Size  Chunks  Chunk Names
4:18:03 PM: newGFEntry.js  2.46 KiB       0  newGFEntry
4:18:03 PM: Entrypoint newGFEntry = newGFEntry.js
4:18:03 PM: [0] ./newGFEntry.js 1.5 KiB {0} [built] [failed] [1 error]
4:18:03 PM: ERROR in ./newGFEntry.js
4:18:03 PM: Module build failed (from /opt/build/repo/node_modules/babel-loader/lib/index.js):
4:18:03 PM: Error: [BABEL] /opt/build/repo/src/lambda/newGFEntry.js: `babel-preset-gatsby` has been loaded, which consumes config generated by the Gatsby CLI. Set `NODE_ENV=test` to bypass, or run `gatsby build` first. (While processing: "/opt/build/repo/node_modules/babel-preset-gatsby/index.js")
4:18:03 PM:     at loadCachedConfig (/opt/build/repo/node_modules/babel-preset-gatsby/index.js:26:15)
4:18:03 PM:     at preset (/opt/build/repo/node_modules/babel-preset-gatsby/index.js:42:29)
4:18:03 PM:     at async (/opt/build/repo/node_modules/@babel/core/lib/gensync-utils/async.js:33:33)
4:18:03 PM:     at async (/opt/build/repo/node_modules/gensync/index.js:186:15)
4:18:03 PM:     at /opt/build/repo/node_modules/gensync/index.js:216:13
4:18:03 PM:     at Generator.next (<anonymous>)
4:18:03 PM:     at /opt/build/repo/node_modules/@babel/core/lib/config/full.js:213:21
4:18:03 PM:     at Generator.next (<anonymous>)
4:18:03 PM:     at Function.<anonymous> (/opt/build/repo/node_modules/@babel/core/lib/gensync-utils/async.js:16:3)
4:18:03 PM:     at Generator.next (<anonymous>)
4:18:03 PM:     at step (/opt/build/repo/node_modules/gensync/index.js:269:25)
4:18:03 PM:     at evaluateAsync (/opt/build/repo/node_modules/gensync/index.js:291:5)
4:18:03 PM:     at Function.errback (/opt/build/repo/node_modules/gensync/index.js:113:7)
4:18:03 PM:     at errback (/opt/build/repo/node_modules/@babel/core/lib/gensync-utils/async.js:60:18)
4:18:03 PM:     at async (/opt/build/repo/node_modules/gensync/index.js:188:31)
4:18:03 PM:     at onFirstPause (/opt/build/repo/node_modules/gensync/index.js:216:13)
4:18:06 PM: success open and validate gatsby-configs - 0.670s
4:18:07 PM: success load plugins - 1.268s
4:18:07 PM: success onPreInit - 0.047s
4:18:07 PM: success delete html and css files from previous builds - 0.003s
4:18:07 PM: success initialize cache - 0.007s
4:18:07 PM: success copy gatsby files - 0.060s
4:18:07 PM: warning [gatsby-source-wordpress] This version of gatsby-source-wordpress will soon be deprecated.
4:18:07 PM: 	https://www.gatsbyjs.org/blog/2020-07-07-wordpress-source-beta/
4:18:07 PM: success onPreBootstrap - 0.020s
4:18:07 PM: success createSchemaCustomization - 0.004s
4:18:08 PM:  -> wordpress__acf_options fetched : 1
4:18:09 PM:  -> wordpress__acf_posts fetched : 0
4:18:09 PM:  -> wordpress__acf_pages fetched : 9
4:18:09 PM:  -> wordpress__acf_media fetched : 95
4:18:09 PM:  -> wordpress__acf_blocks fetched : 0
4:18:09 PM:  -> wordpress__acf_sliders fetched : 4
4:18:09 PM:  -> wordpress__acf_working_groups fetched : 11
4:18:10 PM:  -> wordpress__acf_coalitions fetched : 16
4:18:10 PM:  -> wordpress__acf_home_resources fetched : 6
4:18:10 PM:  -> wordpress__acf_annual_reports fetched : 6
4:18:10 PM:  -> wordpress__acf_guiding_principles fetched : 3
4:18:10 PM:  -> wordpress__acf_leadership fetched : 9
4:18:10 PM:  -> wordpress__acf_videos fetched : 71
4:18:10 PM:  -> wordpress__acf_infographics fetched : 49
4:18:11 PM:  -> wordpress__acf_events fetched : 20
4:18:11 PM:  -> wordpress__acf_surveys fetched : 44
4:18:11 PM:  -> wordpress__acf_covid_19s fetched : 55
4:18:11 PM:  -> wordpress__acf_copays fetched : 16
4:18:11 PM:  -> wordpress__acf_legislative_advocacy fetched : 22
4:18:11 PM:  -> wordpress__acf_regulatory_advocacy fetched : 5
4:18:11 PM:  -> wordpress__acf_backpages fetched : 21
4:18:11 PM:  -> wordpress__acf_categories fetched : 4
4:18:12 PM:  -> wordpress__acf_tags fetched : 0
4:18:12 PM:  -> wordpress__acf_comments fetched : 0
4:18:12 PM:  -> wordpress__acf_users fetched : 1
4:18:12 PM:  -> wordpress__wp_api_menus_v2 fetched : 1
4:18:12 PM:  -> wordpress__wp_api_menus_menus_items fetched : 1
4:18:12 PM:  -> wordpress__wp_api_menus_menus fetched : 1
4:18:12 PM:  -> wordpress__wp_api_menus_menu_locations fetched : 0
4:18:13 PM:  -> wordpress__PAGE fetched : 9
4:18:13 PM:  -> wordpress__wp_media fetched : 489
4:18:13 PM:  -> wordpress__wp_sliders fetched : 4
4:18:14 PM:  -> wordpress__wp_working_groups fetched : 11
4:18:14 PM:  -> wordpress__wp_coalitions fetched : 16
4:18:14 PM:  -> wordpress__wp_home_resources fetched : 6
4:18:14 PM:  -> wordpress__wp_annual_reports fetched : 6
4:18:14 PM:  -> wordpress__wp_guiding_principles fetched : 3
4:18:14 PM:  -> wordpress__wp_leadership fetched : 9
4:18:15 PM:  -> wordpress__wp_videos fetched : 71
4:18:15 PM:  -> wordpress__wp_infographics fetched : 49
4:18:15 PM:  -> wordpress__wp_events fetched : 20
4:18:15 PM:  -> wordpress__wp_surveys fetched : 44
4:18:16 PM:  -> wordpress__wp_covid_19s fetched : 55
4:18:16 PM:  -> wordpress__wp_copays fetched : 16
4:18:16 PM:  -> wordpress__wp_legislative_advocacy fetched : 22
4:18:16 PM:  -> wordpress__wp_regulatory_advocacy fetched : 5
4:18:16 PM:  -> wordpress__wp_backpages fetched : 21
4:18:16 PM:  -> wordpress__CATEGORY fetched : 4
4:18:17 PM:  -> wordpress__TAG fetched : 17
4:18:53 PM: Normalizing links...
4:18:53 PM: Done!
4:18:54 PM: success Downloading remote files - 36.794s - 489/489 13.29/s
4:18:54 PM: Starting Gravity Forms Source plugin
4:18:54 PM: Using: https://admin.allianceforpatientaccess.org
4:18:54 PM: Basic auth details not included
4:18:54 PM: Fetching form ids
4:18:55 PM: Fetching fields for form 1
4:18:55 PM: Fetching fields for form 2
4:18:55 PM: Processing forms
4:18:55 PM: Completed Gravity Forms Source plugin
4:18:55 PM: success Checking for changed pages - 0.000s
4:18:55 PM: success source and transform nodes - 48.196s
4:18:56 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__wp_copays.acf.link` - [`link`, `link___NODE`]. Gatsby will use `link___NODE`.
4:18:56 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__wp_covid_19s.acf.link` - [`link`, `link___NODE`]. Gatsby will use `link___NODE`.
4:18:56 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__wp_surveys.acf.link` - [`link`, `link___NODE`]. Gatsby will use `link___NODE`.
4:18:56 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__wp_events.acf.link` - [`link`, `link___NODE`]. Gatsby will use `link___NODE`.
4:18:56 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__wp_infographics.acf.link` - [`link___NODE`, `link`]. Gatsby will use `link___NODE`.
4:18:57 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__wp_media.guid` - [`guid___NODE`, `guid`]. Gatsby will use `guid___NODE`.
4:18:57 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__acf_copays.acf.link` - [`link___NODE`, `link`]. Gatsby will use `link___NODE`.
4:18:57 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__acf_covid_19s.acf.link` - [`link`, `link___NODE`]. Gatsby will use `link___NODE`.
4:18:57 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__acf_surveys.acf.link` - [`link`, `link___NODE`]. Gatsby will use `link___NODE`.
4:18:57 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__acf_events.acf.link` - [`link`, `link___NODE`]. Gatsby will use `link___NODE`.
4:18:57 PM: warning Multiple node fields resolve to the same GraphQL field `wordpress__acf_infographics.acf.link` - [`link___NODE`, `link`]. Gatsby will use `link___NODE`.
4:18:58 PM: warning There are conflicting field types in your data.
4:18:58 PM: If you have explicitly defined a type for those fields, you can safely ignore this warning message.
4:18:58 PM: Otherwise, Gatsby will omit those fields from the GraphQL schema.
4:18:58 PM: If you know all field types in advance, the best strategy is to explicitly define them with the `createTypes` action, and skip inference with the `@dontInfer` directive.
4:18:58 PM: See https://www.gatsbyjs.org/docs/actions/#createTypes
4:18:58 PM: GF__Form.confirmations.pageId:
4:18:58 PM:  - type: number
4:18:58 PM:    value: 0
4:18:58 PM:  - type: string
4:18:58 PM:    value: ''
4:18:58 PM: success building schema - 2.680s
4:18:58 PM: info Total nodes: 2296, SitePage nodes: 23 (use --verbose for breakdown)
4:18:58 PM: success createPages - 0.078s
4:18:58 PM: success Checking for changed pages - 0.000s
4:18:58 PM: success createPagesStatefully - 0.098s
4:18:58 PM: success update schema - 0.059s
4:18:58 PM: success onPreExtractQueries - 0.000s
4:19:04 PM: success extract queries from components - 5.534s
4:19:04 PM: success write out redirect data - 0.002s
4:19:04 PM: success Build manifest and related icons - 0.377s
4:19:04 PM: success onPostBootstrap - 0.379s
4:19:04 PM: info bootstrap finished - 62.948s
4:19:13 PM: warning
4:19:13 PM:                  The requested width "600px" for a resolutions field for
4:19:13 PM:                  the file /opt/build/repo/src/images/logo-light.png
4:19:13 PM:                  was larger than the actual image width of 346px!
4:19:13 PM:                  If possible, replace the current image with a larger one.
4:19:20 PM: success run static queries - 15.348s - 20/20 1.30/s
4:19:24 PM: success run page queries - 4.406s - 33/33 7.49/s
4:19:24 PM: success write out requires - 0.009s
4:19:35 PM: warning ⠀
4:19:35 PM: warning warn - Tailwind is not purging unused styles because no template paths have been provided.
4:19:35 PM: warning warn - If you have manually configured PurgeCSS outside of Tailwind or are deliberately not removing unused styles, set `purge: false` in your Tailwind config file to silence this warning.
4:19:35 PM: warning warn - https://tailwindcss.com/docs/controlling-file-size/#removing-unused-css
4:21:23 PM: success Building production JavaScript and CSS bundles - 118.380s
4:21:24 PM: success Rewriting compilation hashes - 0.003s
4:23:45 PM: success Generating image thumbnails - 280.304s - 731/731 2.61/s
4:23:56 PM: success Building HTML renderer - 11.376s
4:23:57 PM: 0 true
4:23:57 PM: 1 true
4:23:57 PM: 2 true
4:23:57 PM: 3 true
4:23:57 PM: { edges:
4:23:57 PM:    [ { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] },
4:23:57 PM:      { node: [Object] } ] }
4:23:58 PM: success Building static HTML for pages - 2.324s - 33/33 14.20/s
4:24:00 PM: warning styles.74297a2fdaf186db7112.css is 4.83 MB, and won't be precached. Configure maximumFileSizeToCacheInBytes to change this limit.warning offline-plugin-app-shell-fallback/index.html is 4.84 MB, and won't be precached. Configure maximumFileSizeToCacheInBytes to change this limit.Generated public/sw.js, which will precache 7 files, totaling 1153878 bytes.
4:24:00 PM: success onPostBuild - 1.126s
4:24:00 PM: info Done building in 358.238 sec
4:24:00 PM: 
4:24:00 PM: (build.command completed in 5m 59.7s)
4:24:00 PM: 
4:24:00 PM: ────────────────────────────────────────────────────────────────
4:24:00 PM:   2. Functions bundling                                         
4:24:00 PM: ────────────────────────────────────────────────────────────────
4:24:00 PM: 
4:24:00 PM: The Netlify Functions setting targets a non-existing directory: lambda
4:24:00 PM: 
4:24:00 PM: (Functions bundling completed in 0ms)
4:24:00 PM: 
4:24:00 PM: ────────────────────────────────────────────────────────────────
4:24:00 PM:   3. Deploy site                                                
4:24:00 PM: ────────────────────────────────────────────────────────────────
4:24:00 PM: 
4:24:00 PM: Starting to deploy site from 'public'
4:24:01 PM: Creating deploy tree asynchronously
4:24:01 PM: Creating deploy upload records
4:24:03 PM: 2 new files to upload
4:24:03 PM: 0 new functions to upload
4:24:03 PM: Site deploy was successfully initiated
4:24:03 PM: 
4:24:03 PM: (Deploy site completed in 3s)
4:24:03 PM: 
4:24:03 PM: ────────────────────────────────────────────────────────────────
4:24:03 PM:   Netlify Build Complete                                        
4:24:03 PM: ────────────────────────────────────────────────────────────────
4:24:03 PM: 
4:24:03 PM: (Netlify Build completed in 6m 2.7s)
4:24:04 PM: Caching artifacts
4:24:04 PM: Started saving node modules
4:24:04 PM: Finished saving node modules
4:24:04 PM: Started saving build plugins
4:24:04 PM: Finished saving build plugins
4:24:04 PM: Started saving pip cache
4:24:04 PM: Finished saving pip cache
4:24:04 PM: Started saving emacs cask dependencies
4:24:04 PM: Finished saving emacs cask dependencies
4:24:04 PM: Started saving maven dependencies
4:24:04 PM: Finished saving maven dependencies
4:24:04 PM: Started saving boot dependencies
4:24:04 PM: Finished saving boot dependencies
4:24:04 PM: Started saving rust rustup cache
4:24:04 PM: Finished saving rust rustup cache
4:24:04 PM: Started saving go dependencies
4:24:06 PM: Finished saving go dependencies
4:24:06 PM: Build script success
4:24:06 PM: Starting post processing
4:24:06 PM: Post processing - HTML
4:24:07 PM: Post processing - header rules
4:24:07 PM: Post processing - redirect rules
4:24:07 PM: Post processing done
4:24:07 PM: Site is live ✨
4:25:34 PM: Finished processing build request in 8m6.819865629s

hrishikesh · June 17, 2021, 5:52am

Hi @avinoamsn,

As far as I’m concerned, the website does load fine even after subsequent reloads. I’m using Safari 14 on MacOS 11.

However, I see that you’ve a service worker for your website. It’s possible that it is the cause of the error. If you are still seeing this problem, I think removing that from your website should help. Do note that, even when you remove the service worker from your website, it still exists in your client’s browser. So, everyone will have to clean the service worker themselves… You can do this using JavaScript, but for that, your website should load.

avinoamsn · June 17, 2021, 3:31pm

Hi @hrishikesh, thanks for the response. As I wrote under Attempted Fixes, I also figured the culprit could be the service worker, but disabling it didn’t appear to change anything. I could try again, although I’m not sure what I would’ve missed the first time.

Interesting to note that you don’t experience the problem in safari - I’ll try that myself. Most of our visitors are using Chrome, and the issue may be specific to the browser.

hrishikesh · June 17, 2021, 4:26pm

I just checked on Chrome and it works fine for me there too.

avinoamsn · June 17, 2021, 7:31pm

You’re able to return to the site after an initial visit without a problem? Do you have caching disabled? I wonder what’s different with your setup.

Could you share your chrome://version info? Here’s mine:

Google Chrome	91.0.4472.106 (Official Build) (64-bit) (cohort: Stable)
Revision	574f7b38e4e7244c92c4675e902e8f8e3d299ea7-refs/branch-heads/4472@{#1477}
OS	Windows 10 OS Version 2009 (Build 19042.1052)
JavaScript	V8 9.1.269.36
User Agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36
Command Line	"C:\Program Files\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=SecurePaymentConfirmation --flag-switches-begin --flag-switches-end

hrishikesh · June 18, 2021, 7:17am

Here you go:

It was a freshly installed Chrome Setup. So, I have not disabled anything yet.

Just checked and the website still loads fine even on my mobile network (using Wi-Fi Hotspot).

avinoamsn · June 18, 2021, 8:51am

Thanks for the info. I’ve investigated further and it looks like the issue isn’t present on OSX devices (only Windows 10) - not sure what this could mean.

I noticed that the Facebook Pixel plugin was erroring out with a similar-looking error on my MacBook (but not breaking the page load), so I tried disabling that, too - but that also hasn’t changed anything.

hrishikesh · June 18, 2021, 8:57am

I’m not sure how a difference of operating systems can lead to such a failure. I’d assume it’s some kind of a configuration that’s causing the problem.

I just checked on my Windows laptop and my phone too. Both running Chrome 91, and the website still loads fine after each refresh.

avinoamsn · June 18, 2021, 9:01am

Guess that invalidates my theory then, haha. You have caching enabled on the devices, yes? The website appears to load fine on my MacBook, but not my Win10 machines. I haven’t had time to try that many configurations, so I’ll need to continue debugging tomorrow.

hrishikesh · June 18, 2021, 9:04am

I’am using Chrome with default settings. So, yeah. All settings are on. If the page was loading, you could have provided us a request ID that we could have used to check this further. But since it’s not loading at all, that’s not possible. After testing on multiple browsers, on multiple devices and networks, I’ve got strong reasons to believe it’s some local configuration issue. But then, I don’t know why the website loads in the first attempt.

avinoamsn · June 20, 2021, 3:37am

Given that the issue is being reported by multiple users, if it’s local than it’s an extremely odd coincidence - definitely proving difficult to establish a pattern with the available data. It wasn’t even occurring for me at first, which leads me to wonder if it’s something that has happened as the result of visiting the site during certain time (or under a set of some other extenuating circumstances).

I’ve re-deployed the dev site with duplicate code & content and the issue hasn’t presented itself to me there (yet), so I’ve sent it out to some colleagues, and pending their feedback I’ll probably re-configure the DNS to point to the dev site before cycling the main site. If you’d like to take a look, the dev site is available at this address: https://afpa-dev.netlify.app/.

Thanks for your assistance on this.

hrishikesh · June 20, 2021, 4:32am

This is really strange then. I hope the fresh URL solves the issue for everyone as I can still see the previous as well as the old URL perfectly fine on all my devices.

I agree there should have been a pattern. Maybe you can try using a VPN if you’re all from the same region?

avinoamsn · June 24, 2021, 8:20pm

Good idea, I’m testing this now. The URL change didn’t solve the issue, but it’s worth noting that I still don’t experience the problem with the default Netlify url (afpa-dev.netlify.app), only the custom domain. Again, not sure if this is enough to say with certainty that the issue lies with the domain.

I’m sharing the network log .har files from a browser that is experiencing the issue (Chrome on Win10). Maybe you can spot something that I’ve missed:

Log

{
  "log": {
    "version": "1.2",
    "creator": {
      "name": "WebInspector",
      "version": "537.36"
    },
    "pages": [],
    "entries": [
      {
        "_initiator": {
          "type": "other"
        },
        "_priority": "VeryHigh",
        "_resourceType": "document",
        "cache": {},
        "request": {
          "method": "GET",
          "url": "https://allianceforpatientaccess.org/",
          "httpVersion": "",
          "headers": [
            {
              "name": "sec-ch-ua",
              "value": "\" Not;A Brand\";v=\"99\", \"Google Chrome\";v=\"91\", \"Chromium\";v=\"91\""
            },
            {
              "name": "sec-ch-ua-mobile",
              "value": "?0"
            },
            {
              "name": "Upgrade-Insecure-Requests",
              "value": "1"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36"
            }
          ],
          "queryString": [],
          "cookies": [],
          "headersSize": -1,
          "bodySize": 0
        },
        "response": {
          "status": 0,
          "statusText": "",
          "httpVersion": "",
          "headers": [],
          "cookies": [],
          "content": {
            "size": 0,
            "mimeType": "x-unknown"
          },
          "redirectURL": "",
          "headersSize": -1,
          "bodySize": -1,
          "_transferSize": 0,
          "_error": "net::ERR_FAILED"
        },
        "serverIPAddress": "",
        "startedDateTime": "2021-06-24T17:49:23.626Z",
        "time": 4.714999930001795,
        "timings": {
          "blocked": 4.714999930001795,
          "dns": -1,
          "ssl": -1,
          "connect": -1,
          "send": 0,
          "wait": 0,
          "receive": 0,
          "_blocked_queueing": -1
        }
      },
      {
        "_initiator": {
          "type": "other"
        },
        "_priority": "VeryHigh",
        "_resourceType": "document",
        "cache": {},
        "request": {
          "method": "GET",
          "url": "https://allianceforpatientaccess.org/",
          "httpVersion": "",
          "headers": [
            {
              "name": "sec-ch-ua",
              "value": "\" Not;A Brand\";v=\"99\", \"Google Chrome\";v=\"91\", \"Chromium\";v=\"91\""
            },
            {
              "name": "sec-ch-ua-mobile",
              "value": "?0"
            },
            {
              "name": "Upgrade-Insecure-Requests",
              "value": "1"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36"
            }
          ],
          "queryString": [],
          "cookies": [],
          "headersSize": -1,
          "bodySize": 0
        },
        "response": {
          "status": 0,
          "statusText": "",
          "httpVersion": "",
          "headers": [],
          "cookies": [],
          "content": {
            "size": 0,
            "mimeType": "x-unknown"
          },
          "redirectURL": "",
          "headersSize": -1,
          "bodySize": -1,
          "_transferSize": 0,
          "_error": "net::ERR_FAILED"
        },
        "serverIPAddress": "",
        "startedDateTime": "2021-06-24T17:49:24.697Z",
        "time": 6.2179999658837914,
        "timings": {
          "blocked": 6.2179999658837914,
          "dns": -1,
          "ssl": -1,
          "connect": -1,
          "send": 0,
          "wait": 0,
          "receive": 0,
          "_blocked_queueing": -1
        }
      },
      {
        "_initiator": {
          "type": "other"
        },
        "_priority": "VeryHigh",
        "_resourceType": "document",
        "cache": {},
        "request": {
          "method": "GET",
          "url": "https://allianceforpatientaccess.org/",
          "httpVersion": "",
          "headers": [
            {
              "name": "sec-ch-ua",
              "value": "\" Not;A Brand\";v=\"99\", \"Google Chrome\";v=\"91\", \"Chromium\";v=\"91\""
            },
            {
              "name": "sec-ch-ua-mobile",
              "value": "?0"
            },
            {
              "name": "Upgrade-Insecure-Requests",
              "value": "1"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36"
            }
          ],
          "queryString": [],
          "cookies": [],
          "headersSize": -1,
          "bodySize": 0
        },
        "response": {
          "status": 0,
          "statusText": "",
          "httpVersion": "",
          "headers": [],
          "cookies": [],
          "content": {
            "size": 0,
            "mimeType": "x-unknown"
          },
          "redirectURL": "",
          "headersSize": -1,
          "bodySize": -1,
          "_transferSize": 0,
          "_error": "net::ERR_FAILED"
        },
        "serverIPAddress": "",
        "startedDateTime": "2021-06-24T17:49:29.726Z",
        "time": 5.991999991238117,
        "timings": {
          "blocked": 5.991999991238117,
          "dns": -1,
          "ssl": -1,
          "connect": -1,
          "send": 0,
          "wait": 0,
          "receive": 0,
          "_blocked_queueing": -1
        }
      }
    ]
  }
}

avinoamsn · June 24, 2021, 9:05pm

I tried visiting the site from various locations using a VPN, which made no difference - which isn’t a huge surprise, because I don’t experience this issue on my MacBook. This brings me back to wondering if this has something to do with visiting the site at certain times, or getting a cookie that causes this to happen after visiting within a certain window.

avinoamsn · June 24, 2021, 11:23pm

After a reset to the very first commit w/ Gatsby (just the default Gatsby template), the site still doesn’t work. The issue must be something to do with some config somewhere. It’s just an immediate failure, no further context provided. This issue is becoming increasingly urgent, as the organisation has an ongoing event at the moment.

avinoamsn · June 24, 2021, 11:43pm

Arg no, it’s most definitely the service worker - once it’s unregistered, the site loads without a hard refresh. I have no idea what I missed the first time around, but our initial instincts were correct. I still don’t know what changed such that the service worker now breaks the site, but it’s at least something.

avinoamsn · June 25, 2021, 12:58am

I’ve opened an issue on the Gatsby GH.

hrishikesh · June 25, 2021, 6:51am

Looks like the issue got closed very fast because of the old version.

I’d advise to not user service worker in the mean-time so that your website “works”, however little slower. You can then take some to maybe diagnose or update the plugin. I remember having issues when that plugin back when I used Gatsby. Long story short, I dropped it and was using: gatsby-plugin-sw | Gatsby. It got the work done back then, but I’m not sure if it will still work or not.