Skip to content

Conversation

@robshakir
Copy link
Member

  * (M) rpc/gnmi/gnmi-specification.md
    - remove references to the deprecated `error` field in the
      `SetResponse` and `UpdateResult` messages, explicitly
      specifying the error handling behaviour follows the standard
      gRPC error model.

Fixes #62.

  * (M) rpc/gnmi/gnmi-specification.md
    - remove references to the deprecated `error` field in the
      `SetResponse` and `UpdateResult` messages, explicitly
      specifying the error handling behaviour follows the standard
      gRPC error model.
Copy link
Contributor

@wenovus wenovus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@wenovus wenovus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dplore noted here that there is ambiguity as to what to return when multiple error codes are valid: #155 (comment)

@dplore
Copy link
Member

dplore commented Jul 8, 2022

In the case of multiple errors, I believe we should specify "the implementation SHOULD return the first error encountered"

As a newcomer to gRPC, I found it useful to directly reference the standard gRPC return codes and this gRPC core doc page on status codes

* When the client specifies a payload utilising an encoding that is not
supported by the target (e.g., JSON) - `Unimplemented (12)` SHOULD be used to
indicate that the encoding is not supported.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* When the client specifies a value which is not permitted by the target - `Unimplemented (12)`
SHOULD be used. For example, setting an interface full_duplex leaf to false when the interface
only supports full_duplex.

Copy link
Member

@dplore dplore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please consider comments on

  • additional use case for unimplemented (12) and In the case of multiple errors
  • I believe we should specify "the implementation SHOULD return the first error encountered"

As a newcomer to gRPC, I found it useful to directly reference the standard gRPC return codes and this gRPC core doc page on status codes

I found these more straightforward to read than the referenced gRPC error handling guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

errors in SetResponse (proto vs. spec)

3 participants