| Commit message (Collapse) | Author | Age |
| |
|
|\
| |
| | |
Run pylint test in Python 3
|
| |
| |
| |
| |
| |
| | |
* 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
|
|/
|
|
|
|
|
|
| |
* Use latest pylint in Python 3.7 (they dropped support for PY2)
* Make latest pylint happy
* Forced to upgrade to shellcheck 0.4.4
* Make shellcheck 0.4.4 happy
* Adopt reviewers' advice to reduce global disabled rules
|
|
|
|
| |
* Using the proprocess command to copy the LICENSE
|
| |
|
| |
|
|\
| |
| | |
Configure module level loggers with basicConfig().
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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:`
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Upgrade yapf version to 0.20.0 and reformat Python files.
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\
| |/
|/| |
|
| | |
|
|/ |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
I made this mistake in 2010985ab269c8df0443e4f3782cbdffb083e9d4 but
only with yesterday's release of six 1.11.0 has it started failing
("TypeError: metaclass conflict: the metaclassof a derived class must
be a (non-strict) subclass of the metaclasses of all its bases").
|
| | |
|
|/
|
|
| |
(The server-related third part of it.)
|
|
|
|
| |
(The channel-related second part of it.)
|
|
(The time-related first part of it, anyway.)
|