| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
The Beta API has an execution date and RPC Framework is but a distant
memory.
This test is flaky with Python 3.5 on Windows! Some mysteries will just
have to remain unsolved...
|
|\
| |
| | |
Verify early OK behavior.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Looks like early OK support was implemented in
https://github.com/grpc/grpc/pull/14080 but
https://github.com/grpc/grpc/issues/7032 was not marked fixed at the
time.
Good thing it was just an idea on our Google Summer of Code ideas
page...
|
|/
|
|
|
| |
Structures the libuv implementation to allow for a plugable
BSD style socket implementation to allow for other IO Managers
|
| |
|
|\
| |
| | |
Update third_party/boringssl to the latest chromium-stable
|
| | |
|
|\ \
| | |
| | | |
Remove Python background poller thread
|
| |/
|/| |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
|\| | |
|
| | | |
|
|\| | |
|
| | | |
|
| |/ |
|
| | |
|
|/ |
|
| |
|
|\ |
|
| |\
| | |
| | | |
C++ Resolver API
|
|\| | |
|
|\ \ \ |
|
| | |/
| |/| |
|
| | |\
| | |/
| |/| |
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
The thread that watches connectivity on the channel might not
pick up that the server has gone away before the request is
dispatched, and return UNAVAILABLE instead of reconnecting
prior to sending the request. The fundamental solution would
basically be enabling retries in C-core. For now, we opt to
sleep a second to deflake this particular test case.
|
| |\
| |/
|/| |
|
|\ \
| | |
| | | |
Remove alarm from core, implement in C++ layer only
|
| | | |
|
|\ \ \
| | | |
| | | | |
Elide cygrpc.ChannelArg and cygrpc.ChannelArgs.
|
|\ \ \ \
| | | | |
| | | | | |
Rename GTS to ALTS for TSI plugin
|
| | | | | |
|
| |_|_|/
|/| | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
fix-stream-compression-config-interface
|
| | | | | |
|
| | | |/
| | |/| |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A gRPC Python client interceptor is passed an instance of a class
that implements the ClientCallDetails interface. The interceptor
can choose to create its own object that implements the interface,
and pass it back to the continuation invoked by the interceptor.
To make it easy to add additional attributes to call details,
without breaking user code that hardcode the attributes required
by the interface, instead of interospecting the object passed
to the interceptor at runtime, and to ease authorship of
interceptors that want to keep some attributes intact and not
care about them, we relax the requirements on the object that
is expected to get passed by the interceptor and let the user
omit some attributes. Omitted attributes will be replaced
by the original value of the attribute given to the interceptor.
|
| | | |
|
| | | |
|
|\| |
| | |
| | |
| | | |
fix-stream-compression-config-interface
|
| | | |
|
| | | |
|
| |\ \
| | |/
| |/| |
python: Context.abort should fail RPC even for StatusCode.OK
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
grpc.ServicerContext.abort is documented to always raise an exception
to terminate the RPC. The code argument "must not be StatusCode.OK."
However, if you do pass StatusCode.OK, the RPC terminates successfully
on the client side, but returns None.
_server.py: If the user accidentally passes StatusCode.OK, treat it as
StatusCode.UNKNOWN. This is what happens if the user accidentally
passes something that is not a StatusCode instance. Additionally
set details to ''.
_metadata_code_details_test.py: update test to verify the behavior of
abort with invalid codes.
|
| |/ |
|