Skip to content

grpc: always check value of returned grpc::Status.#6917

Closed
PiotrSikora wants to merge 1 commit intoenvoyproxy:masterfrom
PiotrSikora:fixup_grpc_status
Closed

grpc: always check value of returned grpc::Status.#6917
PiotrSikora wants to merge 1 commit intoenvoyproxy:masterfrom
PiotrSikora:fixup_grpc_status

Conversation

@PiotrSikora
Copy link
Copy Markdown
Contributor

Fixes Google import, since grpc::Status is internally annotated
with warn_unused_result.

Signed-off-by: Piotr Sikora piotrsikora@google.com

Fixes Google import, since grpc::Status is internally annotated
with warn_unused_result.

Signed-off-by: Piotr Sikora <piotrsikora@google.com>
@PiotrSikora
Copy link
Copy Markdown
Contributor Author

cc @jplevyak

// lifetime of the Slice(s) exceeds our Buffer::Instance.
std::vector<grpc::Slice> slices;
byte_buffer.Dump(&slices);
RELEASE_ASSERT(byte_buffer.Dump(&slices) == grpc::Status::OK, "");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Please explain what happens in the rc details failure. Should this only happen if the machine is out of memory? If it can otherwise fail we should probably do error handling instead

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@alyssawilk Good call!

It looks like this can fail for various reasons (e.g. uninitialized buffer, decompression errors when input buffer is compressed), but GoogleGrpcUtils::makeBufferInstance() is only used in tests, so I'm not sure how much we care about those...

@jplevyak any plans for this function to be used for real traffic? Perhaps we should move it into tests?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

#6525 is under active review

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If it's only in test today I'd also be OK with landing this as-is to unblock merge with a TODO to do the error handling as part of #6525, if @jplevyak is up for doing the error handling.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Oops, sorry, I totally missed this one.

@jplevyak do you want to incorporate those changes into #6525 or should I return nullptr in case of errors in this PR?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I can do the error handling. The question is what is most appropriate. Since the ByteBuffer is coming from the low level gRPC library, the most likely causes would be a bug in that library or memory corruption. This would suggest that a RELEASE_ASSERT at that level would be appropriate. WDYT? Alternatively an Exception or at critical log?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

From looking at the gRPC code, it seems that Dump() (well, grpc_byte_buffer_reader_init()) can fail because of decompression errors, which means that if someone sends corrupted gRPC message, then Dump() would return error, so we should treat it as invalid request/response, and not runtime error.

@alyssawilk alyssawilk self-assigned this May 14, 2019
@stale
Copy link
Copy Markdown

stale bot commented May 21, 2019

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added stale stalebot believes this issue/PR has not been touched recently and removed stale stalebot believes this issue/PR has not been touched recently labels May 21, 2019
@stale
Copy link
Copy Markdown

stale bot commented May 30, 2019

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label May 30, 2019
jplevyak added a commit to jplevyak/envoy that referenced this pull request Jun 5, 2019
See envoyproxy#6917 for details.

Signed-off-by: John Plevyak <jplevyak@gmail.com>
@PiotrSikora
Copy link
Copy Markdown
Contributor Author

Closing (incorporated in #6525).

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

Labels

stale stalebot believes this issue/PR has not been touched recently

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants