Gatsby: TypeError: Cannot read property 'address' of null

[SachaG]

I've started getting this error when running gatsby develop:

error UNHANDLED REJECTION


  TypeError: Cannot read property 'address' of null

  - develop.js:371 _callee3$
    [StateOfJS]/[gatsby]/dist/commands/develop.js:371:38

  - next_tick.js:131 _combinedTickCallback
    internal/process/next_tick.js:131:7

  - next_tick.js:180 process._tickCallback
    internal/process/next_tick.js:180:9

I'm on Mac OS High Sierra with Node 8.9.1. I first got the error while using Node 9 so I downgraded and the error went away, but I noticed that hot module reloading wasn't working. From reading #864 I got the idea to try gatsby develop --host localhost --port 8000 instead of gatsby develop, but then that triggered the address error again.

I'm not sure what's going on exactly… Could it be related to my own config somehow?

[KyleAMathews]

What version of Gatsby? I just made a PR with the develop command so could have added a bug https://github.com/gatsbyjs/gatsby/pull/2951

[artfaktor]

I have this error too. I am trying out the gatsby-starter-blog and it seemed fine until I started to add my own images to one of the sample .md files.
I haven't changed anything except this one .md file.
I'm using Windows 10, Node.js 6.9.2 (x64), and only installed gatsbyjs a few days ago so presume it is the latest version.

[Magneticmagnum]

I am also getting this when starting tutorial-part-three as part of the tutorial!

[email protected]

NPM version 4.2.0
Node version 7.10.0

[KyleAMathews]

Could y'all try 1.9.118?

[artfaktor]

Thanks @KyleAMathews,
[email protected] but I still get the same error.

[KyleAMathews]

So I managed to reproduce this by dropping down to [email protected] but then managed to "fix" it by opening up node_modules/gatsby/dist/commands/develop.js and saving the file (triggering a Prettier run).

It seems to be some sort of timing bug? E.g. the server hasn't finished starting yet.

[Magneticmagnum]

@KyleAMathews - That seemed to resolve the issue when I'm now on 1.9.118.

However, going back to a different project I had (not the tutorial-part-three), it seems none of my images are able to load. They get the following error in the web console:

0.0.0.0:8000/static/bar.66fc6cc3.jpeg:1 GET http://0.0.0.0:8000/static/bar.66fc6cc3.jpeg net::ERR_ADDRESS_INVALID

[Magneticmagnum]

Perhaps still something to do with the address refactoring from #2951.

My dev site is located at localhost:8080. I'll try to help debug it. Perhaps we should reopen this issue.

[rdela]

I experienced this issue for the first time today and resolved it by updating to [email protected] and re-running gatsby develop, on node 8.9.1, gatsby 1.9.118, no host, localhost, or port specified either time.

[SachaG]

Just tested with [email protected] and [email protected], same thing. gatsby develop works but no HMR, gatsby develop --host localhost --port 8000 triggers the error.

[rdela]

Yep. Can repro.
gatsby develop --host localhost --port 8888
triggers error.

Interestingly,
gatsby develop --port 8888
does not, and visiting http://localhost:8888/ works.

@SachaG thoughts?

[SachaG]

@rdela is hot module reloading also broken for you?

[rdela]

Error seems to be specific to passing --host localhost for me. Passing
gatsby develop --host 0.0.0.0 --port 8888
works, displays

Local: http://localhost:8888/
On Your Network: http://[xxx].[xxx].[xxx].[xxx]:8888/

as with gatsby develop --port 8888, On Your Network is my correct IP that works for local network testing, and visiting localhost:8888 works.

(Checking on HMR.)

[rdela]

@SachaG ~HMR working with gatsby develop --host 0.0.0.0 --port 8888~

[rdela]

@SachaG ~same for plain gatsby develop --port 8888~

[rdela]

@SachaG @KyleAMathews wait, I got it to break. Which port I set, 8000 or 8888, makes no difference, and whichever working command I use, I get this console error and warning below on compile with plain gatsby develop, --host 0.0.0.0 and --port 8000 or just --port 8000, at first compiled successfully and site updated, now compiles but HMR hosed. Weird because HMR was working, then stopped. [EDIT: In hindsight, not so weird because I think I was hitting http://0.0.0.0:8000/ when HMR worked, not http://localhost:8000/ or http://127.0.0.1:8000/ which turns out to matter, see comments below]

Console error and warning make me think there is confusion between localhost and 0.0.0.0 happening.

Console output (gatsby develop version)
Error

localhost/:1 Failed to load http://0.0.0.0:8000/[xxxxxxxxxxxxxxxxxxxx].hot-update.json: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access.

then
bootstrap [yyyyyyyyyyyyyyyyyyyy]:25 XHR finished loading: GET "http://0.0.0.0:8000/[yyyyyyyyyyyyyyyyyyyy].hot-update.json".

then Warning

process-update.js:136 [HMR] Update check failed: Error: Manifest request to http://0.0.0.0:8000/[xxxxxxxxxxxxxxxxxxxx].hot-update.json timed out.
    at XMLHttpRequest.request.onreadystatechange (http://localhost:8000/commons.js:34:23)

Only failure to build I have is with passing --host localhost, where I get the UNHANDLED REJECTION that prevents compile.

(Apologies for mixing up 8000 and 8888 so many times, I ran the commands with several variations and was copying from them as I wrote this.)

[rdela]

Console error and warning make me think there is confusion between localhost and 0.0.0.0 happening.

Could be CORS related too, or both? On the Failed to load […]hot-update.json error in console:

No 'Access-Control-Allow-Origin' header is present […]

[rdela]

Yeah CORS looking like the culprit https://github.com/gatsbyjs/gatsby/issues/2956#issuecomment-345560772

[kildareflare]

Also seeing this. Steps:
1) clone starter blog
2) npm install
3) gatsby develop

windows 10 x64
node 8.9.1
gatsby-cli 1.1.22

[rdela]

Ok so seems http://0.0.0.0:8000/ is only IP working with HMR

[rdela]

@SachaG can you try hitting http://0.0.0.0:8000/ instead of http://localhost:8000/ or your local IP and confirm if HMR works for you?

[rdela]

I ran more tests specifying host and port with
gatsby develop --host 0.0.0.0 --port 8000
and used http://0.0.0.0:8000/ instead of localhost and HMR works

Same for gatsby develop --host 0.0.0.0 --port 8888
and http://0.0.0.0:8888/ HMR works

[rdela]

gatsby develop --host bob.dev --port 8888 triggers the

error UNHANDLED REJECTION


  TypeError: Cannot read property 'address' of null

  - develop.js:369 _callee3$

error exactly like gatsby develop --host localhost --port 8888

[rdela]

Since #2951 packages/gatsby-cli/src/create-cli.js now sets defaultHost to 0.0.0.0 instead of localhost

https://github.com/gatsbyjs/gatsby/commit/6ddcc6d971e56e973fc80ea3beff8347c66e7b29#diff-dfccf547543bb987b0ff0a7281348933R17

Then in packages/gatsby/src/commands/develop.js seems we end up always following if (isUnspecifiedHost) path in prepareUrls

https://github.com/gatsbyjs/gatsby/commit/6ddcc6d971e56e973fc80ea3beff8347c66e7b29#diff-346c3005d97c1ca0b5efb170af1b43f6R258

where

prettyHost = `localhost`

__not__ 0.0.0.0

https://github.com/gatsbyjs/gatsby/commit/6ddcc6d971e56e973fc80ea3beff8347c66e7b29#diff-346c3005d97c1ca0b5efb170af1b43f6R261

so we never hit the else where prettyHost = host so does not matter what startServer is doing? …Can we just swap 0.0.0.0 for localhost there and resolve for now?

https://github.com/gatsbyjs/gatsby/commit/6ddcc6d971e56e973fc80ea3beff8347c66e7b29#diff-346c3005d97c1ca0b5efb170af1b43f6R323

Or maybe startServer logic is part of the bug as well? I will read through what led to #2951 changes and then see if I can get my fork working with some kind of patch.

[rdela]

Opened #2970 swapping 0.0.0.0 in for localhost as prettyHost in isUnspecifiedHost section of /packages/gatsby/src/commands/develop.js L259. This restores HMR in URL printed to terminal post-gatsby develop because ends up printing Local: http://0.0.0.0:8000/. This matches host (0.0.0.0) of requests getting blocked by CORS as cross-site due to localhost mismatch described above and by @benforshey in https://github.com/gatsbyjs/gatsby/issues/2956#issuecomment-345560772
It’s a fix, but may not be the right fix. Maybe we want to solve the opposite way or this could be only a symptom or part of a larger problem. Hope it helps @SachaG @KyleAMathews @kildareflare @Magneticmagnum @artfaktor

[SachaG]

HMR does work on http://0.0.0.0:8000/! I'll just use that from now on :)

[sebastienfi]

0.0.0.0 is not universal, this address that binds _any interface_ in UNIX does not exists in Windows.
Having 0.0.0.0 on a side and localhost on the other will also yield CORS issues.

[artfaktor]

Thanks everyone for all your efforts to try and rectify this issue. Swapping '0.0.0.0' in for 'localhost' as prettyHost didn't make any difference for me. I still get the error message. Perhaps because I'm on Windows.
I'm not a developer so can't help with investigation unfortunately. Thanks.

[sebastienfi]

We have the bug also, latest version of Gatsby and CLI.

[rdela]

Thought I remembered Windows having to do with the change. Seems using 0.0.0.0 in place of localhost in the browser (which one can do without touching the code, just do not specify host or will get error) is only a temp. workaround for Mac/Unix devs who need HMR right now.

Means we need to figure out where/why defaultHost from gatsby-cli (0.0.0.0) ends up being set as host for font serving and HMR update json and thus conflicting with prettyHost in develop.js, which leads to the compatible but distinct URIs not passing CORS origin check during development on a Mac. This may overlap what is also causing similar issues on Windows, the error when passing host part especially.

@artfaktor, @sebastienfi, so on Windows you can both gatsby develop but HMR is broken? What happens when you pass gatsby develop --host localhost? Compile error Sacha posted originally? (Same as passing --host bob.dev for me.)
No pressure, I should be able to test on Windows tonight, thanks again :)

Edit: remove en dash add back auto-converted hypens

[rdela]

2852 #2837 may shed some light

Gonna look through changes and try to fix Mac localhost in a couple hours and update or open new PR, let me know if/when I should close #2970 or if anyone has any hunches

[rdela]

This seems especially relevant https://github.com/gatsbyjs/gatsby/issues/2837#issuecomment-343023777
Think program.host in the webpack config snippet @JLongley links to is one of the values that ends up set to 0.0.0.0 instead of localhost when HMR breaks using localhost

[rdela]

Hi everyone please try latest release

• [email protected]
• [email protected]

npm update -g
(all global pkgs) or
npm update -g gatsby-cli
(just gatsby-cli)
https://docs.npmjs.com/cli/update#updating-globally-installed-packages

And see https://github.com/gatsbyjs/gatsby/pull/2983#issuecomment-346115283 and below about Chrome secure origin console errors, we may make more adjustments but HMR working for me in all scenarios!

@artfaktor, @sebastienfi if either of you can try on Windows that would be killer, otherwise hope to get to it late tonight or tomorrow, thanks!

[benforshey]

@rdela I can confirm the that this update fixed the CORS error. Thanks!

[artfaktor]

@rdela updating gatsby-cli has resolved this issue for me too. Thank you.

[rdela]

@benforshey @artfaktor thank you both for testing!

@SachaG (+ others on Mac) are you seeing secure origin Chrome errors in my #2983 comments? Any opinion on localhost vs 127.0.0.1 as future default Mac/*nix dev URL vs lobbying Chrome for inclusion of 0.0.0.0? @sebastienfi ? Guess we need to decide whether to open new issue or continue that discussion here, @KyleAMathews (+ everybody) you have a preference?

[sebastienfi]

With the latest version atm of Gatsby, Gatsby-cli, running gatsby develop produces :
On Windows, a link to localhost is generated, HMR is working, no CORS issue.
On Mac, a link to locahost is generated, HMR is broken, CORS issues are showing. After launching the site this way, on Mac if you navigate to 0.0.0.0:8000 then everything works and no CORS.

My 2 cents on this : localhost is more widely supported, and the fact that 0.0.0.0 doesn't exists on Windows, makes localhost a better candidate in my opinion.

[yeskunall]

This problem still exists with gatsby-cli version 1.1.25. 😞

ping @KyleAMathews!

[KyleAMathews]

@yeskunall what version of gatsby? (not the cli)

[yeskunall]

@KyleAMathews 1.9.118!

[KyleAMathews]

Just tried a site with 1.9.128 and couldn't reproduce

[yeskunall]

You're absolutely right. I guess it's my fault for not looking at the whole thread more carefully. It does work with gatsby@latest. I'd like to point out however, that gatsby-starter-blog is still using v1.9.118, which is why I got that error above. If you'd like, I can make a PR to fix that issue over at gatsbyjs/gatsby-starter-blog!

[KyleAMathews]

That'd be great! We need to automate the upgrading of starters.

On Wed, Dec 6, 2017, 7:25 PM Kunall Banerjee [e-mail]
wrote:

You're absolutely right. I guess it's my fault for not looking at the
whole thread more carefully. It does work with gatsby@latest. I'd like to
point out however, that gatsby-starter-blog is still using v1.9.118, which
is why I got that error above. If you'd like, I can make a PR to fix that
issue over at gatsbyjs/gatsby-starter-blog!

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/gatsbyjs/gatsby/issues/2960#issuecomment-349851674,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEVh8zwTfhzs-WxCHwmgscwsreiIZYtks5s91qogaJpZM4QjOgw
.

[KyleAMathews]

Due to the high volume of issues, we're closing out older ones without recent activity. Please open a new issue if you need help!