Open ipmonk opened 2 years ago
With the workaround in place, there appears to be multiple packets which fail to parse correctly, before it returns data:
% python3 subscribe.py Parsing of telemetry information is failed. Parsing of telemetry information is failed. Parsing of telemetry information is failed. \<snip> Parsing of telemetry information is failed. Parsing of telemetry information is failed. {'update': {'update': [{'path': 'value', 'val': 33572}, {'path': 'value', 'val': 34081}, {'path': 'value', 'val': 0}, {'path': 'value', 'val': 0}, {'path': 'value', 'val': 0}, {'path': 'value', 'val': 0}, {'path': 'value', 'val': 0}, {'path': 'value', 'val': 0}, {'path': 'value',...
hey @ipmonk Thanks for flagging. It is quite curios, what Juniper sends that it is not parsable.. Did you talk to them about the issue? I'd agree that workaround may be a good way to go. Thanks Anton
Hi Anton,
debugged this further, it is getting tripped up by this path:
update {
path {
elem {
name: "state"
}
elem {
name: "temperature"
}
elem {
name: "instant"
}
}
val {
json_val: ""
}
}
'Traceback (most recent call last):\n File "/Users/foo/scripts/foo/gnmi-scripts/venv/lib/python3.9/site-packages/pygnmi/client.py", line 1135, in telemetryParser\n update_container.update({'val': json.loads(update_msg.val.json_val)})\n File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/json/init.py", line 346, in loads\n return _default_decoder.decode(s)\n File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/json/decoder.py", line 337, in decode\n obj, end = self.raw_decode(s, idx=_w(s, 0).end())\n File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/json/decoder.py", line 355, in raw_decode\n raise JSONDecodeError("Expecting value", s, err.value) from None\njson.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "/Users/foo/.vscode/extensions/ms-python.python-2022.18.2/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_resolver.py", line 192, in _get_py_dictionary\n attr = getattr(var, name)\nAttributeError\n'
However, If I change the encoding to PROTO, we get this data, and no crash is seen.
update {
path {
elem {
name: "state"
}
elem {
name: "temperature"
}
elem {
name: "instant"
}
}
val {
float_val: 47 <<<<<<
}
}
According to JNPR, PROTO is the recommended encoding when using Subscribe() That said, they are looking into why JSON encoding isn't returning a value. IMO, the error checking in pygnmi should be improved to handle cases where unexpected values are returned. Alternatively, you could enforce PROTO as the only supported encoding for Subscribe()
Another example of json_val which causes an exception:
update {
path {
elem {
name: "state"
}
elem {
name: "temperature"
}
elem {
name: "instant"
}
}
val {
json_val: "\360\341B\355\375\177"
}
}
Crash seen when connecting to a Juniper box running Junos: 21.4R2-S1.12-EVO
resulted in an unhandled exception:
workaround was to add a line to client.py in _merge_updates()