Type of issue

• Bug
• Enhancement
• Compliance
• Question
• Help wanted

Current Behavior

Context
Subscription holds a dictionary of all the monitored items. New items are added to the subscription via AddItems. Each item holds a created flag which is initially false. Once CreateItems is called, all the items having created = false are collected from the dictionary and transformed into CreateMonitoredItemsRequest which is sent to the server.

Possible bug
When multiple threads are used to create monitored items, each thread can freely call CreateItems.
Thread 1 accesses the dictionary, reading all the uncreated nodes from it. During this read, the dictionary is locked.
Once the read is over, the lock is dropped and requests are sent to the server. While thread 1 is awaiting a response to come back from the server, the monitored item's created flag stays in false state.

Before the response comes back, any other thread can read the dictionary and get the same, uncreated (yet requested) monitored item from the dictionary and include it to the new request. Now the same monitored thread is included in two separate requests and being created twice. This scenario is illustrated in the picture below. Now we have two monitored items in the server and notifications are sent twice to the same monitored node on the client-side.

Green color: thread 1
Orange color: thread 2

Question
I guess, it's legit to be able to have create multiple monitored items for the same node when explicitly done so. To me, the current behavior feels very subtle.
Is this behavior known and intended? Basically, a developer must know that calling CreateItems is not thread-safe while calling AddItems is.

Expected Behavior

No response

Steps To Reproduce

No response

Environment

Opc.Ua.Client 1.4.367
Opc.Ua.Core 1.4.367

Anything else?

No response