ReadIOCompletion error closes port after flush on Windows

[monkbroc]

• SerialPort Version: 6.0.4
• NodeJS Version: v8.7.0
• Operating System and Hardware Platform: Windows 10 64-bit

Summary of Problem

Calling serialPort.flush on Windows causes the Reading from COM port (ReadIOCompletion): Operation aborted error if the port is currently listening which leads to _disconnect being called and the port being closed.

The same code works on Linux with serialport 6. It also works on Windows with serialport 4.

I ran into this issue upgrading the Particle CLI to serialport 6.

Steps and Code to Reproduce the Issue

/* Flash this program to a Particle or Arduino device

void setup() {
	Serial.begin(9600);
}

void loop() {
	if (Serial.available()) {
		char c = Serial.read();
		Serial.printlnf("Char %d", c);
	}
}

Install serialport and run this script on Windows
npm install serialport
node index.js

Expected output:
Char 65

write done

Char 65
write done

Actual output:
Char 65

write done
write done
closing
{ Error: Reading from COM port (ReadIOCompletion): Operation aborted disconnected: true }


*/

const SerialPort = require('serialport');

// Replace with the serial port of your device
const port = 'COM16';
const serialPort = new SerialPort(port, {
	baudRate: 9600,
	autoOpen: false
});
serialPort.on('data', data => {
	console.log(data.toString());
});
serialPort.on('close', err => {
	console.log('closing');
	console.error(err);
	process.exit(0);
});
function sendCommand() {
	serialPort.flush(() => {
		serialPort.write('A');
		serialPort.drain(() => {
			console.log('write done');
		});
	});
}

serialPort.open(err => {
	if (err) {
		console.error(err);
		process.exit(1);
	}
	sendCommand();
	setTimeout(sendCommand, 1000);
});

[mumairofficial]

I have same issue... upon flush it close the connection and if I don not flush then second reponse twisted and merged into first response and make invalid response.

@reconbot This is friendly question; Is there any progress on this issue :)

[SirUppyPancakes]

Also seeing this issue.

Currently, it is important (though not completely a blocking issue) that I flush the buffers before each write during a real-time writeLine-readLine loop where each, last command may fail to respond and could corrupt the next command, and clearing the buffers before each write greatly reduces the chances of corrupted data.

I'll be commenting out my flush() call for now and keeping an eye on the roadmap for the bug-fix, hopefully it will be soon :)

[maxwellhadley]

Any update on progress fixing this issue?

[reconbot]

It needs a champion.