Error reporting in GetResponse and SetResponse

[KookyMonster]

In section 3.3.2 for GetResponse the spec dictates:

The target MUST generate a Notification message for each path specified in the client's GetRequest

Similarly in section 3.4.2:

response - containing a list of responses, one per operation specified within the SetRequest message. Each response consists of an UpdateResult message

However all uses of the "Error" message have been deprecated, so what is a "Notification" or "UpdateResult" message supposed to be populated with in the event of an error? Implementing the spec as written suggests we would simply construct messages of the respective type using the default constructor and attach empty messages but if that's the case why even include them at all?

Prior to this deprecation (version < 0.4.0) of the "Error" message the SetRequest had a great deal of flexibility with the ability to report exactly which operation within the request caused the error and I was hoping that same level of detail would eventually be available for Get RPCs but it seems the opposite stance was taken in this newest version of the spec. Is there a reason for reducing the level of error reporting available?

[robshakir]

I expect that the error is populated as is demonstrated in https://github.com/google/gnxi/blob/master/gnmi/server.go#L621 -- essentially, when one returns an error, the payload of the returned message is null, and the error code that is returned is a status.

The detail is possible to report in a status proto. Its definition is here: https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto

Since the details field is specified to be a google.protobuf.Any field, then any protobuf message can be packed into that field. (It's actually a repeated, so you can pack N error messages there.) This is something that could be done with the gNMI Error message too.

The reason for this change was that we wanted to adopt more common gRPC error handling patterns in the specification -- such that common patterns of checking the status that was returned by the RPC could be used. Previously, the code that the gRPC transport would return (even if error were set) would be OK -- this led to non-idiomatic implementations of client handling code.

[KookyMonster]

I was more concerned with what the Notification and/or Update messages in a GetResponse or the UpdateResult messages of a SetResponse would look like in the face of an error given the sections I quoted. For example if a GetRequest contains 3 paths, where the 2nd path causes a failure ie

GetRequest: <
    path: <
        elem: <
            name: "validPath
        >
    >
    path: <
        elem: <
            name: "BADAPPLE"
        >
    >
    path: <
        elem: <
            name: "otherValidPath"
        >
    >
>

Then from my interpretation of the spec the GetResponse might look as follows:

GetResponse: <
    Notification: <
        Update: <
            path: <
                elem: <
                    name: "validPath
                >
            >
            val: <
                string_val: "some data"
            >
        >
    >
    Notification: <
        Update: <
            path: <
                elem: <
                    name: "BADAPPLE
                >
            >
            val: <
                ???????????????????????????????? <-- What goes here?
            >
        >
    >
    Notification: <
        Update: <
            path: <
                elem: <
                    name: "otherValidPath
                >
            >
            val: <
                string_val: "some other data"
            >
        >
    >
>

And the Status returned might be:

Status: <
    code: NOT_FOUND
    message: "Requested path not found"
>

Since the 2nd path failed, does the content of the "Val" for that "Update" simply become a dontcare? Do we still have to create "Notification" objects for all other "Path" messages in the request even though we know we're in an errored state? (as per 3.3.2 and 3.4.2) Or does that only apply in the case where there are no errors?

Due to the lack of "Error" message within a Notification/Update/UpdateResult it is also difficult and tedious for the client to determine what aspect of their request led to the error. Is the details field intended to provide this information as you explained? ie. in the case of the above errored request we might populate "details" with the "path" that led to the failure:

Status: <
    code: NOT_FOUND
    message: "Requested path not found"
    details: <
        path: <
            elem: <
                name: "BADAPPLE
            >
        >
    >
>

[marcushines-zz]

for Subscribe() you would see this behavior: if "BADAPPLE" doesn't "exist" as a valid leaf nothing should be returned and only the two valid paths should be returned if "BADAPPLE" is a "syntactically invalid" path meaning it can never exist the whole RPC should fail and return an error as it's status. however for Get() I will let someone else comment for sure

…

On Mon, Nov 20, 2017 at 7:37 AM KookyMonster ***@***.***> wrote: I was more concerned with what the Notification and/or Update messages in a GetResponse or the UpdateResult messages of a SetResponse would look like in the face of an error given the sections I quoted. For example if a GetRequest contains 3 paths, where the 2nd path causes a failure ie GetRequest: < path: < elem: < name: "validPath > > path: < elem: < name: "BADAPPLE" > > path: < elem: < name: "otherValidPath" > > > Then from my interpretation of the spec the GetResponse might look as follows: GetResponse: < Notification: < Update: < path: < elem: < name: "validPath > > val: < string_val: "some data" > > > Notification: < Update: < path: < elem: < name: "BADAPPLE > > val: < ???????????????????????????????? <-- What goes here? > > > Notification: < Update: < path: < elem: < name: "otherValidPath > > val: < string_val: "some other data" > > > > And the Status returned might be: Status: < code: NOT_FOUND message: "Requested path not found" > Since the 2nd path failed, does the content of the "Val" for that "Update" simply become a dontcare? Do we still have to create "Notification" objects for all other "Path" messages in the request even though we know we're in an errored state? (as per 3.3.2 and 3.4.2) Or does that only apply in the case where there are no errors? Due to the lack of "Error" message within a Notification/Update/UpdateResult it is also difficult and tedious for the client to determine what aspect of their request led to the error. Is the details field intended to provide this information as you explained? ie. in the case of the above errored request we might populate "details" with the "path" that led to the failure: Status: < code: NOT_FOUND message: "Requested path not found" details: < path: < elem: < name: "BADAPPLE > > > > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALKGm1KiGVgvie2uzZyckUeCYwJP3hpzks5s4Zy9gaJpZM4Of4rm> .