client: Failure to decode server response leads to broken session #170
Comments
|
I was also wondering if this is related to #145 (the type of the |
|
Sorry, I just realised the patch attached won't work on master. I'll rework it and post an update. |
|
0001-samples-Simple-client-to-read-nodes.patch.txt This one should work. |
|
I think the problem is simple, currently there is no support for Variants containing other Variants. That is why you get "Unrecognized encoding mask", because in the EncodingMask case there is no match for Variant (24u8). |
|
Yes - I'm fine with the support lacking though. What I don't want is the client closing the connection when it fails to decode a server reply. I would like that to be handled more gracefully, by an Err(_) being returned to the caller. I'm happy to author a patch and open a PR, but I think I would need some guidance on where the behavior needs changing. |
|
At this point the error is getting converted. For better diagnoses we should forward the error there. opcua/core/src/comms/chunker.rs Lines 248 to 262 in 64844b9 And here is the code where the connection is terminated, when decoding a message fails. opcua/client/src/comms/tcp_transport.rs Lines 604 to 619 in 64844b9 Here there should be some recovery or better handling of the decoding error. On the other hand I am working on a pr for implementing Variant::Variant. |
|
So I'm with you this far:
|
|
I've merged this so retest and see if it fixes the issue here. Weird for the server to nest variants in variants though |
|
Nested variants are used if you accept any datatype, or many datatypes, so you use BaseDataType as datatype for the variable. |
|
I'll test it right away.
This is what I'm trying to get at - is this the desired behaviour? |
Tested and works, so I guess we can close this. I'll open another issue if I want to work on the "client failed to decode server response, session terminated" thing. FWIW it's not a nested Variant types, it's an Array of Variant, I think. Here's the log output: All the variants are then Int32, for whatever reason... |
This takes a little explaining, so I'll start with the steps to reproduce:
Steps to reproduce
$ docker run --rm -d --net host --name opcplc mcr.microsoft.com/iotedge/opc-plc:latest --pn=50000 --ph=localhost --autoaccept --sph --sn=5 --sr=10 --st=uint --fn=5 --fr=1 --ft=uint --ctb --lsn --ref --gn=5 -utApply this patch: 0001-samples-Simple-client-to-read-nodes.patch.txt on masterEDIT: Please grab the patch attached in a comment below.cd samples/read-clientRUST_OPCUA_LOG=debug cargo runI get the following log:
output log
Where I see the breakdown is the line "Unrecognized encoding mask"
For some reason, this shuts everything down and the read attempt eventually times out. But the session is broken in some way at this point, subsequent reads also time out.
In the code sample there are two nodes.
n1produces this problem, butn2does not (a value is returned). Swapping the order of the nodes, first gives a value, then it crashes.So far what I've figured is that
from_encoding_mask()does not handleVariant. I don't know why this is, and I don't know if this is the real problem. What I would like though, is that a read that fails to decode is just returned to me as an error like everything else, so I, as the client, can decide on how to act. As it stands, the only way I can see to recover is to re-initialize the client, but that seems like overkill.The signature of
from_encoding_mask()was changed recently (in 633b60a) and the change from a panic to returning an error looks like the right direction, but it doesn't fully solve this issue.The text was updated successfully, but these errors were encountered: