Gatsby: Cannot forward websocket connection due to randomized statusServerPort

[polarathene]

Description

An error about reaching a random websocket port not being reachable, as Docker cannot be configured to know in advance what the random port will be.

Steps to reproduce

Start up a develop instance of gatsby, in browser devtools inspect websocket connections. There should be two, one is to the proxy port(definable via --port), while the other is for the statusServerPort and is always random.

Expected result

It should be configurable via either option or environment variable, so that a specific port can be specified.

Actual result

Cannot configure, inability to forward the randomized port prevents server status communication.

Problem location

https://github.com/gatsbyjs/gatsby/blob/be78563b70f07f3e9ffb4b65182ffa18a2d11712/packages/gatsby/src/commands/develop.ts#L134-L140

Should be fairly trivial to fix this by passing a value to getRandomPort(), such as program.statusPort or process.env.GATSBY_PORT_STATUS?

[mxstbr]

We want to avoid users connecting to this endpoint manually _and_ exposing any kind of configuration for this, as we don't want to add this to be public API surface. Doing so would add more scrutiny due to the increased stability requirements that I don't currently want to support. That means any kind of environment variable is probably not the right call.

However, we definitely cannot have users seeing errors that they did not cause in their browsers. Since this endpoint is only used to prompt users to restart the develop process when the gatsby-config.js file changes, I would say we simply disable that functionality should the websocket endpoint be inaccessible!

[polarathene]

We want to avoid users connecting to this endpoint manually _and_ exposing any kind of configuration for this, as we don't want to add this to be public API surface.

Some users that have run into this issue(wasn't me personally) prefer to use Docker for Gatsby development, but without a way to configure the port, that functionality would be unusable. Is it wrong to support the DX in this case and outright remove the functionality instead that you're suggesting as a fix?

Doing so would add more scrutiny due to the increased stability requirements that I don't currently want to support. That means any kind of environment variable is probably not the right call.

A port number for development purposes configured by an env var or CLI option is a stability issue? If the env var or option were removed/renamed, all that would happen is the port would go back to be randomized, that's what the function currently does(it's just not passed any default port to try).

I would say we simply disable that functionality should the websocket endpoint be inaccessible!

I think that's a good idea, but still believe being able to use the functionality via configurable port would be nice. It doesn't have to be an official/documented API, exposing experimental/internal APIs can be done without any guarantees, so that anyone using it is aware of such risks if something were to change and break.

[Vinlock]

I'm directly encountering this issue since we generally maintain full development environments within docker. It's nice to be able to have everything up and running with a .env file and one command. I feel as though it's reasonable for a dev environment to be fully configurable via environment variables.

I agree with @polarathene's suggestion in adding an environment variable and defaulting to the randomized port. Shouldn't the developer be able to optionally take control of their development environment to avoid any compatibility issues by nature?

[bensaufley]

Currently Dockerizing a Gatsby project and encountered this. I think it would be useful to be able to standardize the port—I'm unclear, after reading the discussion here, on why that would be a bad thing to allow.

But if it is truly bad to add that configurability, it still might be worth documenting in one way or another because I've got a Network tab full of failed requests that I had to dig through the source code to figure out what it even meant before finding my way here. No permutation of socket.io gatsby port got me here; I ended up searching the sources in Chrome Inspector for the port, finding it mapped to developstatusserver in localhost:…/___services, and then working from there to find where it was set as getRandomPort().

[jasonlimantoro]

Well, that's unfortunate, as that also means we just straight up can't use gatsby with Docker, unless you can ignore all the errors below (and more as another second goes by).

Whether it is disabling or customizing that functionality, I don't really mind both ideas as long as the errors get away.

[polarathene]

Well, that's unfortunate, as that also means we just straight up can't use gatsby with Docker

It'd be a non-issue for production deployments via Docker. Since you're using it for development though, the current workaround to avoid the problem relies on modifying the package in node_modules, as long as that file isn't modified you'd be ok. A proper fix would be good though.

As we're nearing 2 weeks without a response, and with the others chiming in that a PR might be welcomed? I've stopped using Docker for gatsby related development, but it should be a fairly simple PR to put together(supporting a user specified port, not sure how the suggested "fix" of detecting the issue and hiding the errors is meant to be approached), if anyone wants to work on that.

[polarathene]

PR available.

[Samic8]

I am having the same issue when trying to use Gatsby in a docker container. It would be helpful to be able to specify the port.

[polarathene]

Just subscribe to the PR or this issue, it's ready for merging but the core team seems to be a bit busy this week (perhaps some event). They've decided on exposing an environment variable that your docker container can use.