-
Notifications
You must be signed in to change notification settings - Fork 12k
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
serve crashes on websocket close #11156
Comments
Same |
+1 |
1 similar comment
+1 |
Hello, ` Package Version@angular-devkit/architect 0.13.6 Proxy configuration is : var process = require("process");
var BACKEND_PORT = process.env.BACKEND_PORT || 8443;
const PROXY_CONFIG = [
{
context: ["/api"],
target: "https://localhost:" + BACKEND_PORT,
secure: false,
logLevel: "info"
},
{
context: ["/event"],
target: "wss://localhost:" + BACKEND_PORT,
ws: true,
secure: false,
logLevel: "info"
},
];
module.exports = PROXY_CONFIG; Whenever Backend is stopped, ng server crashes with:
Same issue occurs on Windows 10. Thanks in advance for any help. |
+1 |
As a workaround, you can put var process = require('process');
process.on('uncaughtException', function(err) {
// Prevent ECONNRESET errors
// handle the error safely
console.log(err)
}); somewhere in ng serve script, |
Same issue. |
Is there a chance to raise the priority of this issue? Do you know any workarounds different than editing module code directly? cc @filipesilva |
It doesn't sound like the correct way to address this problem is to add a process wide handler. Other, non-webpack, parts of Angular CLI might have legitimate reasons to emit those errors too. As far as the proxy server is concerned, we mostly just pass it on to https://webpack.js.org/configuration/dev-server/#devserverproxy. Maybe there's a bug in |
Totally agree.
Could you help us with describing the problem in the Webpack issue tracker? You have more knowledge of how Angular CLI uses the Dev Server and that might help. Thanks for the quick response! |
The best way to go about these reports is to make a repro that the maintainers can run locally and see the problem happening. Angular CLI requires the proxy file and then puts it in the webpack config: angular-cli/packages/angular_devkit/build_angular/src/dev-server/index.ts Lines 657 to 671 in 8543bf7
For a webpack-dev-server repro you don't need to do this. It's enough to just put it in the config. A minimal repro would have a very basic webpack config (e.g. build a index.js that contains a console.log), and the bare minimum dev server options (just the proxy stuff). Then whatever else you need to see the error. Make a github repository with that code, and then you can open an issue in https://github.com/webpack/webpack-dev-server for it. |
could this be related? change to |
Thanks for reporting this issue. This issue is now obsolete due to changes in the recent releases. Please update to the most recent Angular CLI version. If the problem persists after upgrading, please open a new issue, provide a simple repository reproducing the problem, and describe the difference between the expected and current behavior. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug Report or Feature Request (mark with an
x
)Area
Versions
npm 6.1.0
Angular CLI: 6.0.7
Node: 10.3.0
OS: darwin x64
Angular: 6.0.3
Repro steps
Run the cli serve command with proxying to a backend websocket server(turn
"ws":true
on for one of your endpoints) and return an error from the websocket server. The cli proxy server will crash with the error below.Specifically if you return an http error status code before the websocket request is upgraded to the websocket protocol. Here is the server returning the error code(it's in golang) but you can roughly see that in this example the error returned is well before the protocol change so it is just a regular http 403 error.
The log given by the failure
Desired functionality
The cli proxy dev server should support returning websocket errors to the client instead of crashing.
Mention any other details that might be useful
The text was updated successfully, but these errors were encountered: