| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
* Add `abort_with_status` method in ServicerContext
* Add `Status` interface similar to the design of Details in interceptor
* Add 3 unit test cases for abort mechanism
|
|
|
|
|
|
| |
Appease the yapf gods
Reformat
|
|
|
|
| |
This reverts commit a20e2073c1c53cbdd81a4fb750982a0b13e0c24e.
|
|
|
|
|
|
|
|
|
|
|
| |
Module level loggers were introduced to gRPC Python in 06e1683, but
missed configuring these, leading to 'No handler found for module'
errors. Using the root logger implicitly calls basicConfig() which does
the basic configuration for the logging system by creating a
StreamHandler with a default Formatter and adding it to the logger. But
this is not the case for module level loggers.
Fix this issue by explicitly calling logging.basicConfig().
|
|\
| |
| |
| |
| | |
nathanielmanistaatgoogle/generic-rpc-handler-validation
Check conformance to grpc.GenericRpcHandler type.
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
All logging in Python so far was done with the root logger, resulting
in logs like: `ERROR:Exception calling application:`. With module-level
loggers, the logs will instead include the module in which the
exception is raised: `ERROR:grpc._server:Exception calling application:`
|
|
|
|
|
| |
This is no longer needed with the addition of a close() API that allows
clean shutdown.
|
|\
| |
| | |
Elide cygrpc.ChannelArg and cygrpc.ChannelArgs.
|
| | |
|
|\ \
| |/
|/| |
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.
|
|/ |
|
|
|
|
| |
Upgrade yapf version to 0.20.0 and reformat Python files.
|
|
|
|
|
|
| |
Rather than single classes they are now broken up into class families
with each class containing only those fields and methods that are
needed in the context in which the class is used.
|
|
|
|
|
|
|
|
|
| |
It is now a family of classes conforming to an interface rather than a
single class no single instance of which makes use of all behavior
scoped to the class.
It also now only uses gRPC Core memory for the time of a single batch
rather than for the entire lifetime of the instance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we set the call state to "CANCELLED" after
grpc_cancel_all_calls, we would block other start batch
operations from happening. The rpc_state for the cancelled
call would still be in the server's rpc_states set, but it
would never get removed because there were no active batches
for the call, and the only place we remove from rpc_states is
when a batch completes.
It is better to rely on c-core's cancellation. Once a call
is cancelled, all subsequent ops on that call will return
immediately with a cancellation error.
The RLock() change is due to the possibility that
_on_call_completed
gets invoked immediately when the call has already completed when the
rpc_future callback is created.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
gRPC Python required RPCs terminating with non-OK status code to still
return a valid response value after calling set_code, even though the
response value was not supposed to be communicated to the client, and
returning None is considered a programming error.
This commit introduces an alternative mechanism to terminate RPCs by
calling the `abort` method on `ServicerContext` passed to the handler,
which raises an exception and signals to the gRPC runtime to abort the
RPC with the specified status code and details.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
If the server is already serving max requests, return RESOURCE_EXHAUSTED
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In _server.py start_server_batch_result is removed because
start_server_batch can only ever fail as a result of a programming
defect in gRPC Python and not the application. This differs from some
analogous-appearing points in _channel.py where the result of
start_client_batch is checked because at those points it is possible
for a failure to indicate a programming defect on the part of the
application.
|
| |
|
| |
|
|
|
|
| |
This reverts commit 5e01e2ac977655aa074faf7fde0a74298f5e4c55.
|
| |
|
|\
| |
| | |
Fix grpc._server._Context.time_remaining.
|
| |
| |
| |
| | |
A weak test is included; proper test coverage will come later.
|
|\| |
|
| | |
|
|/
|
|
|
|
|
| |
This reads directly off of the slices rather than ref'ing and unref'ing
them. There's likely some silliness w.r.t. interned slices and
references to them outliving their associated call objects, but we are
just ignoring that for now.
|
|
|
|
| |
This reverts commit 3045a379aa76ce9ee930f427daa4ee799b0162aa.
|
|
|
|
|
|
|
|
| |
The server cleanup method is untested.
The join() function that exposes it is only called by the internals of threading.py, and we don't hold a reference to the server thread to explicitly join() it, and I'm not sure we should add a reference just for this purpose.
Moreover, the threading.py only calls join(None), the code path in question isn't even exercised by the internals of threading.py. Its just there to make sure we properly follow the join(timeout) semantics.
|
|\
| |
| | |
v1.0.x → master upmerge.
|
| | |
|
|/ |
|
|\
| |
| | |
Make handlers optional at server construction
|
| |
| |
| |
| |
| |
| | |
This ensures sync calls get cancelled after
a keyboard interrupt, as well as all calls
getting destroyed before grpc_shutdown()
|
|/ |
|
|
|
|
|
|
|
|
|
| |
This impacts the following APIs:
Metadata: Key is always a str, Value is bytes for binary metadata,
str otherwise
Call Details: str type
gRPC method: str type
hostname/target: str type
|
|\
| |
| |
| |
| | |
nathanielmanistaatgoogle/unimplemented-for-cardinality-violation
UNIMPLEMENTED status for cardinality violation
|