Vscode-specific issue with node-xmlhttprequest-sync: crashes Extension host in Windows; error is caught in MacOS; works as expected (no error) in Linux.

[lopezvoliver]

Type: Bug

I am developing an extension that wraps some features from the @google/earthengine javascript API.

Some of these features can be called either synchronously or can be provided with a callback function. The following minimal reproducible example works as expected when running directly in node, regardless of the environment or OS:

var ee = require("@google/earthengine");
var token=process.env.EETOKEN;
ee.data.setAuthToken('', 'Bearer', token, 3600, [], 
()=>{
    ee.initialize(null, null, 
    ()=>{
        function print(a){
            console.log(a);
        }
        ee.String("Hello from callback")
        .getInfo(print);
        console.log(
        ee.String("Hello from synchronous request")
        .getInfo()
        );
    }, 
    undefined, null, "earthengine-legacy"
    );
    }, false);

where EETOKEN is a short-lived token required to use the earthengine API.

However, running this same code from within a vscode extension results in very different behavior depending on the OS:

• In Linux, it works as expected.
• In MacOS, the following error is caught by my extension and thus neither my extension nor the Extension Host crashes.

  • Error: EROFS: read-only file system, open '.node-xmlhttprequest-sync-32376'

• In Windows, the error isn't caught neither by my extension nor by the Extension host, and the Extension host crashes. Attempting to activate any extension fails until the window is Reloaded. Even attempting to report the issue through Help > Report Issue fails.

Given that the error doesn't occur anywhere when running through node, i.e. it is vscode-specific, I don't expect this to be a bug in the earthengine api. Therefore, I am opening the issue here.

Here is an animation showing the extension working as expected in WSL:

Here is an animation showing the extension working as expected in Windows (with the synchronous call removed):

Finally, here is an animation showing the behavior of the Extension host when the synchronous call is included in Windows:

• We can see that the gee-community.eetasks extension is activated (activationEvent: 'onCommand:eetasks.run') but no error is reported.
• Attempting to use another extension (e.g. open a Jupyter interactive window) fails, although we do see the "Activating extensions.. " in the status bar.
• Reloading the window sets the Extension Host back to normal and we can open a Jupyter interactive window normally.

Finally, here is what a minimal extension command would look like to reproduce the issue:

export function activate(context: ExtensionContext) {
  // Create the show hello world command
  const testCommand = commands.registerCommand("hello-world.testCommand", () => {

  var ee = require("@google/earthengine");
  var token=process.env.EETOKEN;
  if(token){
    ee.data.setAuthToken('', 'Bearer', token, 3600, [], 
    ()=>{
      ee.initialize(null, null, 
      ()=>{
        console.log(ee.String("Hello from synchronous request").getInfo());
      }, 
      undefined, null, "earthengine-legacy"
      );
      }, false);
    }

  });

  // Add command to the extension context
  context.subscriptions.push(testCommand);
}

VS Code version: Code - Insiders 1.85.0-insider (b3b84b5, 2023-11-28T12:02:59.475Z)
OS version: Windows_NT x64 10.0.19045
Modes:

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (8 x 3000)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	undefined
Memory (System)	31.79GB (13.19GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (8)

Extension	Author (truncated)	Version
eetasks	gee	0.2.0
python	ms-	2023.20.0
vscode-pylance	ms-	2023.11.10
jupyter	ms-	2023.10.1100000000
jupyter-keymap	ms-	1.1.2
jupyter-renderers	ms-	1.0.17
vscode-jupyter-cell-tags	ms-	0.1.8
vscode-jupyter-slideshow	ms-	0.1.5

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256197
vslsvsres303:30308271
pythontb:30258533
vsc_aa:30263845
pythonptprofiler:30281269
vsdfh931:30280409
vshan820:30294714
vscod805:30301674
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30404738
py29gd2263:30784851
vsclangdf:30492506
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30618038
a9j8j154:30646983
showlangstatbar:30737417
pythonfmttext:30716741
fixshowwlkth:30771523
showindicator:30805243
pythongtdpath:30726887
i26e3531:30792625
welcomedialog:30812478
pythonnosmt12:30779711
pythonidxpt:30768918
pythonnoceb:30776497
asynctok:30898717
dsvsc013:30777762
dsvsc014:30777825
pythonmpswarning:30859870
dsvsc015:30821418
pythontestfixt:30866404
pythonregdiag2:30871582
pyreplss1:30879911
pythonmypyd1:30859725
pythoncet0:30859736
pythontbext0:30879054
accentitlementst:30870582
dsvsc016:30879898
dsvsc017:30880771
dsvsc018:30880772
aa_t_chat:30882232

[lopezvoliver]

After some digging, I found a more concise way to reproduce the error (independent of @google/earthengine):

export function activate(context: vscode.ExtensionContext) {
	// The command has been defined in the package.json file
	// Now provide the implementation of the command with registerCommand
	// The commandId parameter must match the command field in package.json
	let disposable = vscode.commands.registerCommand('test.sync', () => {
	try{
		var XmlHttpRequest = require("xmlhttprequest").XMLHttpRequest;
		let xmlHttp = new XmlHttpRequest();
		xmlHttp.open("GET","",false);
		xmlHttp.send("");
		vscode.window.showInformationMessage(
		"Response is: " + xmlHttp.responseText); // should return undefined
	}catch(err){
		console.log(err);
	}		
	vscode.window.showInformationMessage("Hello world.");

	});

	context.subscriptions.push(disposable);
}

Test in WSL:

In Windows, this crashes the Extension Host.

[lopezvoliver]

After some more digging around.. I think this issue might come from electron.. hopefully anyone here can confirm this?

I made an electron fiddle that (I believe) causes electron to crash. You can find it here:

https://gist.github.com/lopezvoliver/951784c060cd22bba0ef9d4c29019874

[lopezvoliver]

Ok, so after even more testing and from the response I got from the electron team (see issue here), here's an even more direct way to reproduce the inconsistent behavior for the vscode extension in windows vs Linux:

export function activate(context: vscode.ExtensionContext) {
	// The command has been defined in the package.json file
	// Now provide the implementation of the command with registerCommand
	// The commandId parameter must match the command field in package.json
	let disposable = vscode.commands.registerCommand('test.sync', () => {
	try{

        var spawn = require("child_process").spawn;
        var fs = require("fs");

        var contentFile=".node-content-"+process.pid;
        var syncFile = ".node-sync-"+process.pid;

        var execString = "fs=require('fs');"
        +"fs.writeFileSync('"+contentFile+"', '{}');"
        +"fs.unlinkSync('"+syncFile+"');";

        fs.writeFileSync(syncFile,"","utf8");
        var syncProc = spawn(process.argv[0], ["-e", execString]);
        while(fs.existsSync(syncFile)){
                // Wait while the sync file is empty
        }
        var resp = JSON.parse(fs.readFileSync(contentFile, 'utf8'));
        // Kill the child process once the file has data
        syncProc.stdin.end();
        // Remove the temporary file
        fs.unlinkSync(contentFile);

        vscode.window.showInformationMessage("Response is : " + resp.empty);

	}catch(err){
		console.log(err);
	}		
	vscode.window.showInformationMessage("Hello world.");

	});

	context.subscriptions.push(disposable);
}

This sort of simulates what xmlhttprequest does for synchronous requests, and after testing in windows, I can confirm that this reproduces the unresponsive behavior of the Extension host, while in Linux this is not a problem:

According to the electron team in the issue linked above:

It works in Node.js because the module was designed for Node.js and is intending to spawn Node.js with the -e option, an option which Electron does not support.

I made a quick test in Electron, and indeed I can confirm that it does not work, even in Linux. So my conclusion is that there is some vscode magic going on that makes the above example work in Linux..

So.. where is this magic and can it be implemented to work also in Windows?

[lopezvoliver]

Finally, after going down the rabbit hole even more, the issue is process.argv[0], which is what xmlhttprequest uses to launch the synchronous request.

In Windows, this pointed to Code.exe, while in WSL, this pointed to ~/.vscode-server/bin/<some long string here>/node.

With this information, I can now make a patch for this in my extension, so I will close this issue.