react-ssr-setup
react-ssr-setup copied to clipboard
Error: net::ERR_CONNECTION_REFUSED on yarn build
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?
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()
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.
Please check version 2.0.1. Has been merged an hour ago. This should fix it: https://github.com/manuelbieh/react-ssr-setup/commit/87748a63cd3d1926e043ea7f2c75da73c9bcd5cb
@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
Will have to investigate a bit more. I reopened the issue.
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.
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.
Sorry still seeing this error in 657b4e1
Steps to reproduce:
- clone repo
- yarn install
- yarn build
and the build fails with
Error: net::ERR_CONNECTION_REFUSED at http://localhost:8505
Damn 😕
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.
doublechecking now.
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.
(btw thank you so much - i know this must be a huge drag - i really appreciate the help)
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?
That's really annoying.
Man! Im truly sorry. This is such a great project - you deserve better thanks than me whining! Sorry :coffee: 🌹
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?
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.
Really very much appreciated. Thanks
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);
}
});
Weird 🤔 I will have a look at it! Thanks a lot!
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!
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! :-)
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!
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.
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');