Vscode Go debugger freeze on web-socket disconnect

[amiramw]

Description

ms-vscode.Go extension debugger (could be general issue with vscode extension debug) do not handle well server restart or brief web-socket disconnect.

There is a difference between node.js debug and go debug (based on vs-code-ext):

• Node.js: when web-socket disconnects, the debug session resets, the debuggee stops. This behavior seems normal.
• Go: when web-socket disconnects, the debug session on the browser side seems stuck, no button of debug has any effect, and you must reload the webpage entirely to recover. The debuggee continues to run.

Reproduction Steps

• Install ms-vscode.Go version 0.9.2
• Start debug session
• Simulate web-socket disconnect

To simulate web-socket disconnects, one can use this code for reverse proxy, and access theia via port 3001

var express  = require('express');
var app      = express();
var httpProxy = require('http-proxy');
var proxy = httpProxy.createProxyServer({ target: 'http://localhost:3000', ws: true });

var server = require('http').createServer(app);

// proxy HTTP GET / POST
app.get('/*', function(req, res) {
  console.log("proxying GET request", req.url);
  proxy.web(req, res, {});
});
app.post('/*/*', function(req, res) {
  console.log("proxying POST request", req.url);
  proxy.web(req, res, {});
});

// Proxy websockets
server.on('upgrade', function (req, socket, head) {
  console.log("proxying upgrade request", req.url);
  proxy.ws(req, socket, head);
});

server.listen(3001);

OS and Theia version:
OS: Debian GNU/Linux
Thiea: 0.4.0

[PavelSosin]

There are lot of noise around Websocket connectivity between Debugger client and application deployed to Cloud infrastructure. The cause may be not in application or debugger but in intermediate infrastructure layers like Load balancers, proxies, etc. Since debugging scenario involves long periods of inactivity every layer may break connection due to own timeout settings. For example, Microsoft just released patches for vscode debugger https://github.com/Microsoft/vscode-java-debug.
The Websocket reliability depends on how client and server interchange ping and pong frames and communication layer decides that connection broken. The only reliable solution which I found is Google proposal to always encapsulate communications of such type in separate thread/webWorker. It should work well between Google Chrome and Google Kubernetes via GCP.
Please, describe precisely your scenario including where you client and application where deployed to.

[PavelSosin]

To simulate brief Web socket disconnection and re-connection you don't need any plays with cables. Simply re-start pod using the following instruction https://medium.com/devopslinks/how-to-restart-kubernetes-pod-7c702ca984c1 collect all possible logs and attach them to the message as soon as possible. Pod restart is very common scenario for applications under debugging.