ipcRenderer.callMain - subsequent calls return non-resolving Promises

When ipcRenderer.callMain gets called two or more times, the first Promise resolves normally, but subsequent calls return non-resolving Promises. I’m using typescript and electron-webpack. I’ve thrown together a quick bug repro repo to ilustrate the problem. I did a bit of investigation around the method’s source code and found out that in the second call, the callbacks (onData, onError) were not called. But, when I commented out these lines, the issue disappeared (at least for my test case)

ipc.callMain = (channel, data) => new Promise((resolve, reject) => {
	const {sendChannel, dataChannel, errorChannel} = util.getResponseChannels(channel);

	const cleanup = () => {
-		ipc.off(dataChannel, onData);
-		ipc.off(errorChannel, onError);
+		// ipc.off(dataChannel, onData);
+		// ipc.off(errorChannel, onError);
	};

	const onData = (event, result) => {
		cleanup();
		resolve(result);
	};

	const onError = (event, error) => {
		cleanup();
		reject(deserializeError(error));
	};

	ipc.once(dataChannel, onData);
	ipc.once(errorChannel, onError);

In my opinion the off calls are redundant anyways, because the listeners are attached using once, so they will be removed automatically after first event regardless (and that’s what happens after my change, as far as I know). I feel like the double removal might be the issue here.

[maciejewiczow]

For now, my temporary workaround around the issue is to put the following code in the root file of the part of the project that uses electron-better-ipc

if (ipcMain !== undefined)
    ipcMain.addListener('fix-event-798e09ad-0ec6-5877-a214-d552934468ff', () => {});

if (ipcRenderer !== undefined)
    ipcRenderer.addListener('fix-event-79558e00-29ef-5c7f-84bd-0bcd9a0c5cf3', () => {});

No idea why this changes anything though, just stumbled upon it randomly

[maciejewiczow]

Okay, I haven’t thought of this. But nonetheless, something strange is going on here. After another bit of poking around I discovered that adding any listener to ipc emitter before first call to callMain also fixes this issue. I have even less of an idea now as to what might be the cause of this behavior.