Found while developing a client.

While creating MonitoredItem most of the server/client follows this pattern:

1-CreateSubscriptionRequest
< 1-CreateSubscriptionRequest
2-PublishRequest
3-PublishRequest
4-CreateMonitoredItemsRequest
< 4-CreateMonitoredItemsResponse
< 2-PublishRespnse (with Initial values)
5-PublishRequest
< 3-PublishRespnse (with som more values)

Some servers implementation may be publishing DataChangeNotification on new monitored items even before the server had a chance to send the CreateMonitoredItemsResponse to the client (Codesys)

The patterns becomes in this case:

1-CreateSubscriptionRequest
< 1-CreateSubscriptionRequest
2-PublishRequest
3-PublishRequest
4-CreateMonitoredItemsRequest
< 2-PublishRespnse (with Initial values)
5-PublishRequest
< 4-CreateMonitoredItemsResponse <<< LATE
< 3-PublishRespnse (with som more values)

This may cause some initial data change value to never be processed by the client, ( depending on its implementation ) if the actual data recording on the client-side is only effective after the CreateMonitoredItems is completed.

Is this case clearly allowed by the specification?

If yes, shall we describe it in the spec ?

Also this specific scenario would need a CTT unittest ... as some client implementation might miss some

At this time, no CTT test capture this specific edge case.