Error: Number of acknowledgement results (0) does not match number of acknowledgements (1)

[droneconnect]

I am new to opcua-asyncio. Just installed it with pip3 install asyncua I run python 3.8.5 on ubuntu 20.04

I run the https://github.com/FreeOpcUa/opcua-asyncio/blob/master/examples/server-minimal.py and getting an error in uaexpert 1.5.1

could anyone advice? BR Dan

[yichenj]

Same issue. It seems a legacy issue from the sync version. I am looking forward to the fix plan.

[AndreasHeine]

looks like there is a ack or statuscode missing... it actually does not do any bad you still get the notifications in ua expert!

request:

subscription   Acknowledgements [ ] | Subscription Acknowledgement | The list of acknowledgements for one or more Subscriptions. This list may contain multiple acknowledgements for the same Subscription (multiple entries with the same subscriptionId). This structure is defined in-line with the following indented items.

response:

results [ ] | StatusCode | List of results for the acknowledgements (see 7.34 for StatusCode definition). The size and order of the list matches the size and order of the subscriptionAcknowledgements request parameter.

edit:

it appears results is always empty...

[swamper123]

I went back with our versions until v0.9.0, but the issue still exist. So the newer commits haven't made any influence on that.

EDIT: @brubbel mentioned in python-opcua

The way freeopcua works at the moment is that datachanges are published whenever data changes (throttled and multiple changes are bundeled at regular intervals), however this implies that e.g. 2 or more datachange publication-responses may be sent to the client while the client expects a sequential PublishResult.Results for each ack in the publish request, in the order they were issued by the client (flaw in the OPCUA spec imho).

[oroulet]

What is an acknowledgement result? And do we do something wrong?

[AndreasHeine]

https://reference.opcfoundation.org/v104/Core/docs/Part4/5.13.5/

publish response -> results is empty but it must have same number of statuscodes like the number of subscriptionAcknowledgements

[oroulet]

I had a short look at it and in fact looks like we have a parsing bug and something very strange with the statuscode implementation. There is both an enum and a class. And enum should be more than enough i suppose... Must look at it later

[droneconnect]

good stuff! thanks guys for quickly troubleshooting this :).. give us an update when we can test again!

[AndreasHeine]

you can use it anyways that bug does not break anything you will recv all notifications in UA Expert! just kind of ugly in the log...

[yichenj]

Sorry, is this the same issue with the sync version? The sync one looks very complicated and can cause severe result based on the implementation of client.

[oroulet]

@AndreasHeine @swamper123 I tried to do something yesterday: Send results immediatly after receiving acks (2 acks in PublishRequest-> 2 statuscode results in next PublishResponse) But it does not seem to make uaexpert happy. I am not really sure what it wants...

[oroulet]

I am wondering if uaexpert expects the status code in the PublishResponse corresponding to the PublishRequest, but that would be orthogonal to the entire pub/sub system.... We keep a queue/buffer of PublishRequests in server

[AndreasHeine]

@oroulet this is from another server with node-opcua stack: trace1.zip

[brubbel]

I went back with our versions until v0.9.0, but the issue still exist. So the newer commits haven't made any influence on that.

That is because UaExpert only started reporting this in the logs in the more recent versions.

Don't try to decode my answer below word by word (it's been a long time for me), but basically it goes as follows.

1. client sends publication request, which acts a 'token' for the server to send a future datachange.
2. server sends datachange notification (consumes token), pushes a 'pending ack' in an ordered list.
3. client sends new publication request (thus a new token), with embedded ack for notification in (2) Now comes the issue:
4. server sends new datachange notification, with resulting statuscode 'good' after processing the client's ack in (3), then server removes that ack from the list mentioned in (2)

So the idea is here:

• clients sends pub requests. Each request can be used by the server as a token (permission) to send new datachange events.
• server has no tokens left -> stops sending datachange events (1 request = 1 response)

Freeopcua does not implement the token/acking whatever thing. Current implementation of freeopcua is to send datachange events when it feels to (=wrong!)

• At connection/subscription time, the client sends a few requests (tokens) to the server so that the above procedure can be initiated. If I remember correctly (50% chance), 2 requests are queued by uaexpert at any time (but this number can be higher, to handle higher latency for example).

ps: acks are the NotificationMessage.SequenceNumber

Changes required in freeopcua, section internal subscription:

• keep a list of unacked datachanges, implement acking procedure
• keep a dict of triggered datachanges (same for events). instead of immediately publishing, wait for a token (if not enough tokens). If data changes faster than tokens arrive, only keep last change in case of token arrives.

[samxu0823]

I have met the same problem with opcua 0.98.13 and UaExpert1.5.1. Is there a solution right now? Thank you and looking forward to your answer!

[AndreasHeine]

any exception or error? or just the log in uaexpert?

[samxu0823]

only log in UaExpert

[AndreasHeine]

do not worry!