Skip to content

Don't mark server RPC canceled if finished with explicit non-OK status#22991

Merged
vjpai merged 1 commit intogrpc:masterfrom
vjpai:status_error
Jun 11, 2020
Merged

Don't mark server RPC canceled if finished with explicit non-OK status#22991
vjpai merged 1 commit intogrpc:masterfrom
vjpai:status_error

Conversation

@vjpai
Copy link
Copy Markdown
Contributor

@vjpai vjpai commented May 19, 2020

A server call should not be marked canceled if it completes with any status (ok or not OK). It should only be marked canceled if it is terminated before it can successfully send a status to the client (e.g., due to deadline, connection age, network error, etc). This PR does the following:

  1. Decide if a server call is canceled by whether or not it could successfully send status
  2. Fixes core tests (wrapped language tests already had the proper expectations)
  3. Mark a call failed according to channelz if it was canceled or if the server sent a non-OK status
  4. Fix the core surface comment about this topic and bump the core major API version
  5. Add a C++ test to validate that OnCancel is not called on non-OK explicit status

I have also confirmed that the C++ test commit fails without the source commits in this PR but passes with them, so it's a proper validation case.


This change is Reviewable

@vjpai vjpai added the release notes: no Indicates if PR should not be in release notes label May 19, 2020
@vjpai vjpai force-pushed the status_error branch 2 times, most recently from f7dde77 to 287131e Compare May 27, 2020 09:21
@vjpai vjpai changed the title Don't mark cancellation on explicit status Don't mark server RPC canceled if finished with explicit non-OK status May 27, 2020
@vjpai vjpai force-pushed the status_error branch 2 times, most recently from f4a955a to e23919a Compare May 27, 2020 16:35
@vjpai vjpai requested a review from yang-g May 27, 2020 16:37
@vjpai vjpai marked this pull request as ready for review May 27, 2020 16:37
Copy link
Copy Markdown
Contributor

@yang-g yang-g 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
Copy Markdown
Member

@markdroth markdroth left a comment

Choose a reason for hiding this comment

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

Just a few drive-by comments, all minor cosmetic issues.

Thanks for doing this!

Reviewed 52 of 52 files at r1.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @vjpai)


include/grpcpp/impl/codegen/server_context_impl.h, line 182 at r1 (raw file):

  /// connection reset, HTTP/2 parameter configuration (e.g., max message size,
  /// max connection age), etc. It does NOT include failure due to a non-OK
  /// status return, including Status::CANCELLED.

Maybe say "from the server application's request handler", just to be completely clear?


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

  grpc_closure* send_initial_metadata_finished = nullptr;
  grpc_metadata_batch* send_trailing_metadata = nullptr;
  bool* sent_trailing_metadata_op = nullptr;

Suggest calling this trailing_metadata_sent.


src/core/lib/transport/transport.h, line 250 at r1 (raw file):

    // as  a cancellation (since the stream was write-closed before status could
    // be delivered).
    bool* sent_trailing_metadata = nullptr;

This being only one character off of the previous field is likely to cause confusion. How about just calling this sent, and relying on the fact that it's inside of the send_trailing_metadata struct for the additional context?

Copy link
Copy Markdown
Contributor Author

@vjpai vjpai left a comment

Choose a reason for hiding this comment

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

And thanks again for the review!

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @markdroth)


include/grpcpp/impl/codegen/server_context_impl.h, line 182 at r1 (raw file):

Previously, markdroth (Mark D. Roth) wrote…

Maybe say "from the server application's request handler", just to be completely clear?

Done.


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, markdroth (Mark D. Roth) wrote…

Suggest calling this trailing_metadata_sent.

So I'd prefer to keep this to indicate that this is a field of the op. The name trailing_metadata_sent sounds like a bool rather than a bool* . That said, I'd be fine with a different name. Maybe for later re-consideration?


src/core/lib/transport/transport.h, line 250 at r1 (raw file):

Previously, markdroth (Mark D. Roth) wrote…

This being only one character off of the previous field is likely to cause confusion. How about just calling this sent, and relying on the fact that it's inside of the send_trailing_metadata struct for the additional context?

Done.

Copy link
Copy Markdown
Member

@markdroth markdroth left a comment

Choose a reason for hiding this comment

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

Please resolve the one remaining comment before merging. Thanks!

Reviewed 17 of 17 files at r2.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @vjpai)


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, vjpai (Vijay Pai) wrote…

So I'd prefer to keep this to indicate that this is a field of the op. The name trailing_metadata_sent sounds like a bool rather than a bool* . That said, I'd be fine with a different name. Maybe for later re-consideration?

We don't use the _op suffix for any of the other fields that point into the grpc_transport_stream_op_batch_payload struct. Another example of a bool* field is trailing_metadata_available.

Copy link
Copy Markdown
Contributor Author

@vjpai vjpai left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @markdroth)


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, markdroth (Mark D. Roth) wrote…

We don't use the _op suffix for any of the other fields that point into the grpc_transport_stream_op_batch_payload struct. Another example of a bool* field is trailing_metadata_available.

I should have also said: there's already a field called sent_trailing_metadata which is a bool for CHTTP2's internal control, so trailing_metadata_sent would be super-confusing.

Copy link
Copy Markdown
Contributor Author

@vjpai vjpai left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @markdroth)


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, vjpai (Vijay Pai) wrote…

I should have also said: there's already a field called sent_trailing_metadata which is a bool for CHTTP2's internal control, so trailing_metadata_sent would be super-confusing.

How about sent_trailing_metadata_notify ?

Copy link
Copy Markdown
Member

@markdroth markdroth left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @vjpai)


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, vjpai (Vijay Pai) wrote…

How about sent_trailing_metadata_notify ?

This sounds like an argument for a better naming scheme for all of these members, to clarify which ones are for returning values and which ones are for internal state. But I recognize that that may be a larger effort that should be done independently of this PR. Maybe just add a TODO for now?

Copy link
Copy Markdown
Contributor Author

@vjpai vjpai left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @markdroth)


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, markdroth (Mark D. Roth) wrote…

This sounds like an argument for a better naming scheme for all of these members, to clarify which ones are for returning values and which ones are for internal state. But I recognize that that may be a larger effort that should be done independently of this PR. Maybe just add a TODO for now?

TODO sounds good for now. Thanks!

Copy link
Copy Markdown
Contributor Author

@vjpai vjpai left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @yashykt)


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, vjpai (Vijay Pai) wrote…

TODO sounds good for now. Thanks!

TODONE and assigned to @yashykt as the chttp2 owner

Copy link
Copy Markdown
Contributor Author

@vjpai vjpai left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @yashykt)


src/core/ext/transport/chttp2/transport/internal.h, line 536 at r1 (raw file):

Previously, vjpai (Vijay Pai) wrote…

TODONE and assigned to @yashykt as the chttp2 owner

Done.

Copy link
Copy Markdown
Member

@markdroth markdroth left a comment

Choose a reason for hiding this comment

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

Reviewed 1 of 1 files at r3.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

@vjpai
Copy link
Copy Markdown
Contributor Author

vjpai commented Jun 11, 2020

Known failure at #23188

@vjpai vjpai merged commit a1c2f62 into grpc:master Jun 11, 2020
@vjpai vjpai deleted the status_error branch June 11, 2020 22:21
@vjpai
Copy link
Copy Markdown
Contributor Author

vjpai commented Jul 22, 2020

Thanks for the comment! I'll keep that in mind for the future.

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

Labels

area/core lang/c++ lang/core release notes: no Indicates if PR should not be in release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants