This can break subsequently run tests, including any which have already
stored references to gRPC enums (such as grpc.StatusCode.OK). The
subsequent tests will compare now be comparing the old enums to the
reloaded enums, and they will not match. This causes errors in
_metadata_code_details_test and a hang in _metadata_flags_test, when run
in sequence locally after _logging_test.
It's unclear why this has been working on Kokoro, but it is reproducible
locally and is behavior that should be avoided.
* Used in _channel.py, _server.py, and _utilities.py
* This API can trace back to 4 years ago
* The code change ensures the logging info is exactly the same
* 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
This addresses https://github.com/grpc/grpc/issues/17001. Prior to
https://github.com/grpc/grpc/pull/13603, our credentials cython objects
used grpc_initi() and grpc_shutdown() on creation and destruction. These are
now managed differently, but the grpc_init() and grpc_shutdown() calls
are still required. See the MetadataCredentialsPluginWrapper in C++,
which extends the GrpcLibraryCodegen class to ensure that grpc_init()
and grpc_shutdown() are called appropriately.
Without this, we can deadlock when a call to grpc.Channel#close()
triggers grpc_shutdown() to block and wait for all timer threads to
finish: one of these timer threads may end up unreffing the subchannel
and triggering grpc_call_credentials_unref, which will jump back into
Cython and hang when it tries to reacquire the GIL.