[Randomly Situation] Triggering PropertyChanged Event After SetProperty, but WriteRequest Is Not Sent to OPC UA Server

[mark602502]

1. Problem Description (Description)

I’m using the convertersystems/opc-ua-client library to subscribe and write to an OPC UA Server by:

Creating an OpcUaTags class that inherits SubscriptionBase and is annotated with [Subscription(endpointUrl: "server_1", ...)].
Defining a property annotated with [MonitoredItem(nodeId: "ns=2;s=Test.TestTag")].
Using this.SetProperty to update the property value, hoping it will also trigger a write back to the OPC UA Server.

Here’s an example of the code:

private void DoInitialOpcUaApp()
{
    // Create the OPC UA Application
    this._opcUaApp = OpcUaApplicationFactory.Generate(this._loggerProvider);

    // Create a Tag Model that inherits SubscriptionBase
    this._opcUaTags = new OpcUaTags();
    this._opcUaTags.PropertyChanged += OpcUaTags_PropertyChanged; 
    this._opcUaTags.ErrorsChanged += OpcUaTags_ErrorsChanged;

    // Start the connection to the OPC UA Server
    this._opcUaApp.Run();
}

// In another file:
[Subscription(endpointUrl: "server_1", publishingInterval: 100, keepAliveCount: 20)]
public partial class OpcUaTags : SubscriptionBase, IModelGateway
{
    [MonitoredItem(nodeId: "ns=2;s=Test.TestTag")]
    public string Test_TestTag
    {
        get => this._Test_TestTag;
        set => this.SetProperty(ref this._Test_TestTag, value);
    }
}

Expected behavior:
When I run this._opcUaTags.Test_TestTag = "someValue";, it not only triggers the local PropertyChanged event but also sends a WriteRequest to the OPC UA Server through the library. I should see related logs in the console or output window, such as Sending WriteRequest, Handle: xxxxxxx and Received WriteResponse, ....

Actual behavior:
Most of the time, the write request is sent successfully. However, occasionally (and unpredictably), I see that the PropertyChanged event is triggered, but there is no corresponding WriteRequest or WriteResponse log. In other words, that particular update is never written to the server. From the logs, there is no Sending WriteRequest, Handle: xxxxxxx or Received WriteResponse, Handle: xxxxxxx.

2. Environment Information (Environment)

• Library version[convertersystems/opc-ua-client]: 3.2.3
• .NET version: .NET Framework 4.7.2
• OS: Windows 10 64-bit
• OPC UA Server: DeviceXPlorer OPC Server 7

3. Expected Behavior

Execute this._opcUaTags.Test_TestTag = "newValue";.
Triggers the OpcUaTags_PropertyChanged event.
The library sends a WriteRequest to the OPC UA Server, and the logs show:
"Sending WriteRequest, Handle: xxxxxxx"
"Received WriteResponse, Handle: xxxxxxx Result: 0x00000000 (或其他 StatusCode)"

4. Actual Behavior

Most of the time it writes successfully. But occasionally, in a real operational environment, one or several updates show no WriteRequest log, and hence the data doesn’t get written to the OPC UA Server.
The PropertyChanged event is still triggered, yet there is no subsequent write action.

5. Observations / Possible Causes

private async void OnPropertyChanged(object? sender, PropertyChangedEventArgs e)
{
    if (isPublishing || string.IsNullOrEmpty(e.PropertyName) || !monitoredItems.TryGetValueByName(e.PropertyName, out MonitoredItemBase item) || !item.TryGetValue(out DataValue value))
    {
        return;
    }
    .
    .
    .
}

• isPublishing flag
  I suspect that when the server pushes data (causing isPublishing = true), if I happen to call SetProperty at that exact moment, the OnPropertyChanged check sees isPublishing as true and skips the WriteRequest. This might explain why the issue appears intermittently (it depends on precise timing).

• TryGetValueByName / item.TryGetValue(out DataValue)
  It might be that the Subscription dictionary isn’t fully updated yet, or that some node is in an abnormal state (e.g., disposed or re-subscribed), causing the retrieval of DataValue to fail and thus the write gets skipped.

• No WriteRequest in the logs
  Indicates the code never actually reached InnerChannel.WriteAsync (or was caught by an exception handler without logging). I currently don’t see any exceptions, so I doubt that’s the root cause.