Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: net::ERR_CONNECTION_REFUSED on yarn build #26

Open
davidwieler opened this issue Sep 14, 2018 · 24 comments
Open

Error: net::ERR_CONNECTION_REFUSED on yarn build #26

davidwieler opened this issue Sep 14, 2018 · 24 comments
Labels

Comments

@davidwieler
Copy link

When running yarn build, I'm getting this error:
UnhandledPromiseRejectionWarning: Error: net::ERR_CONNECTION_REFUSED at http://localhost:8505

any idea what would cause this?

@davidwieler
Copy link
Author

davidwieler commented Sep 14, 2018

Nevermind, closing this.

I ripped out nodemon and replaced it with forever-monitor.

The build process wasn't truly async, so nodemon was starting after puppeteer was trying to open the page in some cases.

I changed my generateStaticHTML method to this:

const generateStaticHTML = async () => {
    const forever = require('forever-monitor')
    const fs = require('fs')
    const puppeteer = require('puppeteer')

    process.env.PORT = 8505

    const headlessServer = new (forever.Monitor)(`${paths.serverBuild}/server.js`, {
        max: 3,
        silent: true,
        args: []
    })

    headlessServer.on('quit', () => {
        process.exit()
    })

    headlessServer.on('error', () => {
        process.exit(1)
    })

    await headlessServer.start()

    const browser = await puppeteer.launch()
    logMessage('Headless browser started', 'info')
    const page = await browser.newPage()

    logMessage(`Headless browser page opened to http://localhost:${process.env.PORT}`, 'info')

    await page.goto(`http://localhost:${process.env.PORT}`)
    const pageContent = await page.content()

    logMessage(`saving page content: ${pageContent}`, 'info')
    logMessage(`To: ${paths.clientBuild}/index.html`, 'info')

    fs.writeFileSync(`${paths.clientBuild}/index.html`, pageContent)

    await browser.close()

    logMessage('Closing headless browser', 'info')

    await headlessServer.stop()

}

And added: process.exit() after the done logMessage around line 85.

        await serverPromise
        await clientPromise
        await generateStaticHTML()
        logMessage('Done!', 'info')
        process.exit()

@luiscvalmeida
Copy link

I'm having the same issue, I guess the server isn't up when puppeteer tries to access it so it fails. Your solution didn't work for me unfortunately.

@manuelbieh
Copy link
Owner

Please check version 2.0.1. Has been merged an hour ago. This should fix it:
87748a6

@luiscvalmeida
Copy link

luiscvalmeida commented Oct 12, 2018

@manuelbieh nop, now I can't build at all just by cloning the repository, installing dependencies as they are and running yarn build:
Error: net::ERR_CONNECTION_REFUSED at http://localhost:8505

@manuelbieh
Copy link
Owner

Will have to investigate a bit more. I reopened the issue.

@manuelbieh manuelbieh reopened this Oct 12, 2018
@luiscvalmeida
Copy link

luiscvalmeida commented Oct 19, 2018

Thanks @manuelbieh , i'll look into that as well. Also I've noticed that running the start script but with production as the NODE_ENV doesn't generate the client build.
Edit: ok I just noticed on client.prod.js webpack config it was missing the WriteFileWebpackPlugin to make this happen.

@manuelbieh manuelbieh added the bug label Nov 2, 2018
@manuelbieh
Copy link
Owner

The cause for this issue is that the server build is started in the build process to generate the static index.html but is then not properly terminated. So the Express server keeps running and, when you create another build, blocks the port.

@gjhltn
Copy link

gjhltn commented Nov 9, 2018

Sorry still seeing this error in 657b4e1

Steps to reproduce:

  1. clone repo
  2. yarn install
  3. yarn build

and the build fails with

Error: net::ERR_CONNECTION_REFUSED at http://localhost:8505

@manuelbieh
Copy link
Owner

Damn 😕

@manuelbieh manuelbieh reopened this Nov 9, 2018
@manuelbieh
Copy link
Owner

Hm. Can't reproduce with a freshly cloned repo. Have you killed all possibly running node processes before pulling/cloning?

I was able to create 5 consecutive builds without any issues.

@gjhltn
Copy link

gjhltn commented Nov 9, 2018

doublechecking now.

@gjhltn
Copy link

gjhltn commented Nov 9, 2018

By restarting my machine from scratch.... it ran first time, successfully. But. immediately doing yarn build a second time errors again

~/Desktop/react-ssr-setup-master $ yarn build
[...]
[2018-11-09T15:13:09.158Z] App is running: 🌎 http://localhost:8505
✨  Done in 17.91s.
~/Desktop/react-ssr-setup-master  $ yarn build
[...]
Error: net::ERR_CONNECTION_REFUSED at http://localhost:8505

Looking at my activity monitor i can't see any node processes still running at all.

@gjhltn
Copy link

gjhltn commented Nov 9, 2018

(btw thank you so much - i know this must be a huge drag - i really appreciate the help)

@manuelbieh
Copy link
Owner

That's really annoying. I also had the same error for a long time and - at least on my machine - don't have it anymore after I made the change in 657b4e1. So it gets even more difficult to fix if I can't reproduce it anymore 😉

I guess you're using a Mac, right? Which MacOS version? And which Node version?

@gjhltn
Copy link

gjhltn commented Nov 9, 2018

That's really annoying.

Man! Im truly sorry. This is such a great project - you deserve better thanks than me whining! Sorry ☕ 🌹

osx 10.14 / node v11.0.0

fwiw doing lsof -t -i :8505 returns empty and there arent any node processes running. could it be a timing thing?

@manuelbieh
Copy link
Owner

Will have to investigate further. Thanks for reporting!

Timing, possible but not very likely. Will try to reproduce it on my Mac with Node 11 soon.

@gjhltn
Copy link

gjhltn commented Nov 9, 2018

Really very much appreciated. Thanks

@gjhltn
Copy link

gjhltn commented Nov 13, 2018

Been looking at this some more over the weekend and have made some nanoprogress :-)

If I add a simple wait in build.js, it seems to work consistently

ie


function sleep(secs) {
  Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, (secs*1000));
}

[...]

script.on('start', async () => {
        try {
            sleep(2); // <-------- BODGE
            const browser = await puppeteer.launch();
            const page = await browser.newPage();
            await page.goto(`http://localhost:${port}`);
            const pageContent = await page.content();
            fs.writeFileSync(`${paths.clientBuild}/index.html`, pageContent);
            await browser.close();
            script.emit('quit');
        } catch (err) {
            script.emit('quit');
            console.log(err);
        }
    });

@manuelbieh
Copy link
Owner

Weird 🤔 I will have a look at it! Thanks a lot!

@manuelbieh
Copy link
Owner

A colleague of mine told me the same. If that reliably solves this issue I will add it. Maybe my machine is just too fast (i7 HQ-series with 32 gigs of RAM ;)).

Could you do me one more favor and check how low you can set the delay while still being able to create 5 consecutive builds without having that error? I don't want to increase the build time unnecessarily. Thanks!

@gjhltn
Copy link

gjhltn commented Nov 20, 2018

It's a total bodge but ¯_(ツ)_/¯

On my feeble MacBook, I get slightly inconsistent results, so it's hard to make it more fine-grained -sleep(0.2) seems to work consistently, and sleep(0.1) fails often.

sleep(0.15) again seems to work... reliably...??? (i just ran 20 consecutive builds). But the reported build times varied between 9.34 and 11.81s so it all seems a bit concerning! :-)

@manuelbieh
Copy link
Owner

It doesn't really have anything to do with the build but with the time the (Express) server needs to start. My assumption is that the puppeteer process tries to access the server before the server has properly started. Maybe I should have a look at the Node event system and emit and subscribe to events to start puppeteer. Thanks for your help!

@gjhltn
Copy link

gjhltn commented Nov 20, 2018

My assumption is that the puppeteer process tries to access the server before the server has properly started.

Definitely agree

subscribe to events to start puppeteer

That sounds like a much, MUCH better idea than waiting and hoping! Though I guess if there's no convenient hook, it might not be crazy to try to access the server, then if that fails, wait and retry, then wait longer and rety etc??

So many thanks again.

@GAjay
Copy link

GAjay commented Aug 19, 2020

Hi @manuelbieh ,

Please check this point. If I comment the line inside build-ssr.ts line number 38 my production build is running perfectly.

script.emit('quit');

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants