[PR #908] Mitigate race conditions and simplify API invocations #1350

New Issue

claunia · 2026-01-29T16:59:49Z

claunia commented

2026-01-29 16:59:49 +00:00

Original Pull Request: https://github.com/ElectronNET/Electron.NET/pull/908

State: closed
Merged: Yes

There's a major design flaw in the API invocations.

The problem is that requests via socket IO are not numbered (like wiht a serial nr) and there can be only a single listener for a certain event name.
This means that when there's an invocation that is waiting for a return and a second invocation is made, the listener for the previous invocation will never be notified.
In combination with the use of TaskCompletionSource, the resulting behavior is that the tasks of such calls were never transitioned to completion (nor errored, nor canceled).

The result: code that was awaiting such tasks remained hanging forever - possibly even preventing the whole application from finishing gracefully (without needing to be forced to).

This PR simplifies those property invocations and it also mitigates those race conditions in a way that only a single invocation (= single TaskCompletionSource) exists for each method at a time. Subsequent calls are just being returned the same task from the TCS.
There can still be situations where there's no return, that's why the PR also introduces a timeout after which the tasks will be canceled. The duration might be debatable or can be made configurable. It's set to 1s at the moment.

Second benefit is the elimination of load of repetitive code. It reduces BrowserWindow from 1.7k to 1.2k lines.

**Original Pull Request:** https://github.com/ElectronNET/Electron.NET/pull/908 **State:** closed **Merged:** Yes --- There's a major design flaw in the API invocations. The problem is that requests via socket IO are not numbered (like wiht a serial nr) and there can be only a single listener for a certain event name. This means that when there's an invocation that is waiting for a return and a second invocation is made, the listener for the previous invocation will never be notified. In combination with the use of TaskCompletionSource, the resulting behavior is that the tasks of such calls were never transitioned to completion (nor errored, nor canceled). The result: code that was awaiting such tasks remained hanging forever - possibly even preventing the whole application from finishing gracefully (without needing to be forced to). This PR simplifies those property invocations and it also mitigates those race conditions in a way that only a single invocation (= single TaskCompletionSource) exists for each method at a time. Subsequent calls are just being returned the same task from the TCS. There can still be situations where there's no return, that's why the PR also introduces a timeout after which the tasks will be canceled. The duration might be debatable or can be made configurable. It's set to 1s at the moment. Second benefit is the elimination of load of repetitive code. It reduces BrowserWindow from 1.7k to 1.2k lines.

claunia added the pull-request label 2026-01-29 16:59:49 +00:00

claunia closed this issue

2026-01-29 16:59:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Electron.NET#1350