-
-
Notifications
You must be signed in to change notification settings - Fork 32
Confusion from "Error: missing update value/file or path" #640
Comments
Just to throw one more into the pot, here's a different confusing error message which may not be gnmic's fault, but if it's a server error response it could be displayed more clearly. This works:
Now I add something invalid to the end of the path:
I didn't add a colon though. Looking at tcpdump, some communication does take place, and I can see the path in cleartext. "Marshaling" to me normally means "encoding". However i's not clear to me whether the issue is client side with encoding the request, or the Cisco's response is somehow invalid (this is IOS-XR 7.2.2, BTW) in which case the problem is in decoding the response. |
Hi |
Sure (it's
And the good one without:
Hmm, so the bad one really is bad (a JSON object without Might be nice to display this as part of the error though. |
Hi, The comma issue in flags Instead if trying to figure out how different shells and different repeated flags will behave, there are a few other options that can be used to set a more complex value. If you would like to set a compound json value you have a couple of options:
$ cat req_file.yaml updates:
- path: /interfaces/interface[name="Bundle-Ether2"]/subinterfaces
encoding: json_ietf
value:
subinterface:
index: 9876
config:
index: 9876 $ gnmic ... set --request-file req_file.yaml |
Yes and the error is displayed: |
I got it working with
There is StringArray:
Of course, although it doesn't show the actual value it's complaining about (I didn't know about The confusion for me as a user was from seeing "error marshaling message", when to me the problem is unmarshaling the response. Looking at code, I think this is an implementation detail, with a marshal and unmarshal pair. Also, "message" could refer to either the request or the response. Perhaps "error decoding response", or even "error decoding json_ietf_val in response", would be clearer? Cheers, Brian. |
StringArray is what is used right now because StringSlice did too many things under the hood (e.g reading the flag as a CSV line). The flags can also be set from ENV or from a config file, viper does not handle string arrays and slices properly (returns them as a string of comma separated values in both cases), hence the usage of
The error does not happen when reading the value from the received message, it happens when trying to marshal it to JSON to print it out on the terminal. gNMIc reads the json/json_ietf values as []byte, it does not validate that the bytes are valid json on reception. I'm not against adding the name of the message to the logged error. |
I was confused by an error message from gnmic.
The following works (action is performed, response is returned):
The following doesn't work:
Instead this returns "Error: missing update value/file or path". And yet I've provided both a path and a value, and jq confirms the JSON value is valid:
Looking for this error message in the code, I find it here:
These are
[]string
. But from the point of view of a dumb user like me, I think I've provided 1 path and 1 value. Adding-d
flag seems to confirm this:Note that it says that set-update-value is
[]string
, with apparently one element in the list.After digging through the code, I believe the issue is introduced in
SanitizeArrayFlagValue
. First, it strips off any outer pairs of[
and]
. Then it breaks the string on comma, unconditionally. In my case, I have a comma in there, but it's part of a compound value, and it didn't occur to me that it would be split here. The debug output shows the value before the split, and the error message seemed to be telling me I hadn't provided a value, when I had.I suggest the error message could be clarified like this:
"number of update-paths (1) does not match number of update-values (2) or update-files (0)"
Other ideas:
--update-value stringArray (comma separated)
%#v
instead of%+v
--update-value foo --update-value bar
. But I realise that would be an incompatible change to the CLI.Anyway, I hope you don't mind this feedback - thanks for an otherwise great tool!
The text was updated successfully, but these errors were encountered: