[Bug]: ipc Renderer SendSync returning null

[evertonlperes]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Electron Version

12.0.18

What operating system are you using?

macOS

Operating System Version

BigSur 11.6

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

ipcRenderer.SendSync should not returns null and crash the application during E2E tests.

Actual Behavior

There's a high failure rate during E2E testing related to the ipcRenderer.SendSync() returning null, making the test runner failing.
It seems to be an intermittent issue and might be related to racing conditions. The failure rate it's around 65% on both environment (CI and LocalDev) and also visible on Windows, Linux and macOS distributions.
Also, I tried to use different test runners and the problem still happening (jest and mocha).

2021-11-03T21:41:31.820Z DEBUG webdriver: request failed due to response error: javascript error
2021-11-03T21:41:31.821Z WARN webdriver: Request failed with status 500 due to javascript error: Cannot read property 'type' of null

Testcase Gist URL

No response

Additional Information

Looks like some folks already had faced this issue before ( see #25035 and all suggested solution still not working. Also, even the browser logs does not show valuable information that can assist us to find out the root cause.

Create browser config:

 createWindow('preferences', `${ webRoot }/index.html`, {
    width:          940,
    height:         600,
    webPreferences: {
      devTools:           !app.isPackaged,
      nodeIntegration:    true,
      contextIsolation:   false,
      enableRemoteModule: process.env?.NODE_ENV === 'test'
    },
  });
  app.dock?.show();
}

Some thoughts or ideas will be very appreciated.
Thanks.

[codebytere]

Thanks for reporting this and helping to make Electron better!

Because of time constraints, triaging code with third-party dependencies is usually not feasible for a small team like Electron's.

Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

I'm adding the blocked/need-repro label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.

[Rigner]

2021/11/12 18:48:46:570 TypeError: Cannot read properties of null (reading 'type')
    at metaToValue (D:\Giochi\Badlion Client\resources\app.asar\node_modules\@electron\remote\dist\src\renderer\remote.js:250:14)
    at Object.getBuiltin (D:\Giochi\Badlion Client\resources\app.asar\node_modules\@electron\remote\dist\src\renderer\remote.js:360:12)
    at Object.get [as app] (D:\Giochi\Badlion Client\resources\app.asar\node_modules\@electron\remote\dist\src\renderer\remote.js:398:28)
    at Object.get [as app] (D:\Giochi\Badlion Client\resources\app.asar\node_modules\@electron\remote\dist\src\renderer\index.js:4:80)
    at file:///D:/User/Badlion%20Client/resources/app.asar/app/app.js:37:38
    at file:///D:/User/Badlion%20Client/resources/app.asar/app/app.js:153:2

Relevant stack trace (reverse from above):

(function () {'use strict
......all of our code in the file
}()); // Line 153 is here

var app = remote__default['default'].app;

    Object.defineProperty(o, k2, { enumerable: true, get: function() { return m[k]; } });

        get: () => exports.getBuiltin(name)

// THIS IS THE PROBLEM! sendSync() returns a null value instead of a string
const meta = electron_1.ipcRenderer.sendSync(command, contextId, module, getCurrentStack());
    return metaToValue(meta);

NOTE: This is only happening to some users. Not all. We have a similar issue in another location for another user where again we are calling sendSync()

We are on electron 14.2.0 currently. In case this helps: we were previously on 11.X and we were not aware of this issue (maybe it was there and we didn't know about it). Maybe something around this changed?

It is also happening with your official library from https://github.com/electron/remote. We haven't been able to reproduce it on our own machines, it seems like a race condition for some people.

[evertonlperes]

Thanks for sharing your thoughts @PSNRigner

I'm trying to replace all sendSync to invoke but it still being quite flaky on jest executions :(

On Electron 13.X I've noticed an improvement on sendSync and I would say, it reduced the failure rate from 60% to 30%... but still there.

Tried with Electron 13.X and 14.X, but still getting the same error (locally and CI).... not sure how to make it working...

[evertonlperes]

Getting a bit deeper on this issue, I found some strange/interesting logs from the electron-chromedriver.

I found two behaviours that may cause the issue:

1. Chromedriver bind() failed: Address already in use(48). --> tried to add --whitelisted-ips= argument...no luck.
2. After electron/js2c/renderer_init.js execution, the error shows up (not sure the root cause for this, trying to figure it out).

In both cases, still intermittent on different platforms (Windows, macOS and Linux - either dev env and CI). Actually, not sure what's the right direction on debugging this....
If you guys have any tip/insight, it will be very appreciated.

Full logs

chromedriver_electron.log
wdio_electron.log

[1637856878.919][INFO]: Starting ChromeDriver 89.0.4389.69 (22eebf64e034a935ce80d8ed2132c4db98a3a209-refs/heads/master@{#846707}) on port 9515
[1637856878.919][INFO]: Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
[1637856878.921][SEVERE]: bind() failed: Address already in use (48)
[1637856878.921][INFO]: listen on IPv4 failed with error ERR_ADDRESS_IN_USE

[1637944354.740][INFO]: Done waiting for pending navigations. Status: ok
[1637944354.741][DEBUG]: DevTools WebSocket Command: Runtime.evaluate (id=24) E8714E11C394EEAC8E38ABB2BC801305 {
   "awaitPromise": true,
   "expression": "(function() { // Copyright (c) 2012 The Chromium Authors. All rights reserved.\n// Use of this source code is governed by a BSD-style license that can be\n// found in the LICENSE file.\n\n/**\n * Enum f...",
   "returnByValue": true
}
[1637944354.746][DEBUG]: DevTools WebSocket Event: Runtime.consoleAPICalled E8714E11C394EEAC8E38ABB2BC801305 {
   "args": [ {
      "type": "string",
      "value": "(electron) The remote module is deprecated. Use https://github.com/electron/remote instead."
   } ],
   "executionContextId": 2,
   "stackTrace": {
      "callFrames": [ {
         "columnNumber": 608,
         "functionName": "log",
         "lineNumber": 12,
         "scriptId": "149",
         "url": "electron/js2c/renderer_init.js"
      }, {
         "columnNumber": 739,
         "functionName": "",
         "lineNumber": 84,
         "scriptId": "149",
         "url": "electron/js2c/renderer_init.js"
      }, {
         "columnNumber": 6989,
         "functionName": "./lib/renderer/api/remote.ts",
         "lineNumber": 84,
         "scriptId": "149",
         "url": "electron/js2c/renderer_init.js"
      }, {
         "columnNumber": 169,
         "functionName": "__webpack_require__",
         "lineNumber": 0,
         "scriptId": "149",
         "url": "electron/js2c/renderer_init.js"
      }, {
         "columnNumber": 950,
         "functionName": "loader",
         "lineNumber": 76,
         "scriptId": "149",
         "url": "electron/js2c/renderer_init.js"
      }, {
         "columnNumber": 171,
         "functionName": "",
         "lineNumber": 24,
         "scriptId": "149",
         "url": "electron/js2c/renderer_init.js"
      }, {
         "columnNumber": 42,
         "functionName": "addMainProcessModules",
         "lineNumber": 69,
         "scriptId": "802",
         "url": ""
      }, {
         "columnNumber": 4,
         "functionName": "eval",
         "lineNumber": 122,
         "scriptId": "802",
         "url": ""
      }, {
         "columnNumber": 5,
         "functionName": "eval",
         "lineNumber": 128,
         "scriptId": "802",
         "url": ""
      }, {
         "columnNumber": 29,
         "functionName": "executeScript",
         "lineNumber": 481,
         "scriptId": "801",
         "url": ""
      }, {
         "columnNumber": 23,
         "functionName": "",
         "lineNumber": 486,
         "scriptId": "801",
         "url": ""
      }, {
         "columnNumber": 21,
         "functionName": "callFunction",
         "lineNumber": 449,
         "scriptId": "801",
         "url": ""
      }, {
         "columnNumber": 22,
         "functionName": "",
         "lineNumber": 463,
         "scriptId": "801",
         "url": ""
      }, {
         "columnNumber": 2,
         "functionName": "",
         "lineNumber": 464,
         "scriptId": "801",
         "url": ""
      } ]
   },
   "timestamp": 1.6379443547447888e+12,
   "type": "warning"
}
[1637944354.747][DEBUG]: DevTools WebSocket Response: Runtime.evaluate (id=24) E8714E11C394EEAC8E38ABB2BC801305 {
   "result": {
      "type": "object",
      "value": {
         "status": 17,
         "value": "Cannot read property 'type' of null" --> :(
      }
   }
}

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

[github-actions]

This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.

[dtychshenko]

I wanted to share what we found about this issue to hopefully save some time for others.

Our app was using Electron 14.2.9 and was also experiencing this problem where occasionally the IPC communication between the renderer process and the main process would not be established.

This would manifest itself as ipcRenderer.sendSync calls always returning null or ipcRenderer.send messages not being received by the main process.

We were able to reproduce it to a point where we had two identical windows open side by side, and the IPC messages from one window would go through to the main process but messages from the impacted window would not be received by the main process. We bypassed all of our code and got as close to the Electron native code as possible to send the message:

process._linkedBinding('electron_renderer_ipc').ipc.send(false, 'test-message', [{ sample: 'payload' }]);

but the problem still persisted which meant that it was somewhere within the Electron native code.

We eventually came across this pull request, which seemed like it could be related: #32734

This change was released in Electron 18.0.0 and then was back-ported into Electron 17.0.1 and Electron 16.2.6. We upgraded our app to 16.2.6 and, lo and behold, the issue was gone. So if you are experiencing this issue, you'll need these minimum versions.