Embues the status package with the ability to create statuses
from generic errors that implement the interface:
type StatusError interface {
Status() *Status
}
This was designed with the github.com/gogo/protobuf project in mind,
but is implemented in a fashion that makes it accessible to arbitrary
payloads.
Fixes#1885.
* service reflection can lookup enum, enum val, oneof, and field symbols; cache descriptors
* address feedback: don't use mutex, remove unnecessary conditional, make fileDescContainingExtension a func instead of a method
This is pre-work to implementing retry support. Each retry attempt will have its own csAttempt. The fields left in clientStream are the same across all attempts.
ALTS NewClientALTS and NewServerALTS APIs are in the grpc/credentials/alts package. Having the term ALTS in the API names is redundant. This PR removes it.
- Provide AppendToOutgoingContext interface for imrproved performance
over manually creating md and joining with existing md
- Add benchmarks for old/new approaches
Fixes#1390
This change introduces some behavior changes that should not impact users that
are following the proper stream protocol. Specifically, one of the following
conditions must be satisfied:
1. The user calls Close on the ClientConn.
2. The user cancels the context provided to NewClientStream, or its deadline
expires. (Note that it if the context is no longer needed before the deadline
expires, it is still recommended to call cancel to prevent bloat.) It is always
recommended to cancel contexts when they are no longer needed, and to
never use the background context directly, so all users should always be
doing this.
3. The user calls RecvMsg (or Recv in generated code) until a non-nil error is
returned.
4. The user receives any error from Header or SendMsg (or Send in generated
code) besides io.EOF. If none of the above happen, this will leak a goroutine
and a context, and grpc will not call the optionally-configured stats handler
with a stats.End message.
Before this change, if a user created a stream and the server ended the stream,
the stats handler would be invoked with a stats.End containing the final status
of the stream. Subsequent calls to RecvMsg would then trigger the stats handler
with InPayloads, which may be unexpected by stats handlers.
