Allow `CallFilters` to have more than one `CallFilters::Stack` attached to it, and execute all of the stacks when executing.
This permits a trivial implementation of `PassThrough` for `Interceptor`, and allows elimination of an inserted `ForwardCall` if an interception chain terminates in a `CallDestination` preceded by one or more filters.
Built on #36984 which should be merged first.
Closes#36985
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36985 from ctiller:step-by-step 07b14c9d91
PiperOrigin-RevId: 646586483
This test very occasionally needs to have gRPC initialized, so adding the init/shutdown scope just where it's needed.
Closes#37050
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37050 from ctiller:ci 4baad7af76
PiperOrigin-RevId: 646586430
When using gRPC client alongside kopf (Python framework for writing K8s operators), the existing code fails because of 9243c8fbb2/kopf/_cogs/aiokits/aiotoggles.py (L40). This is because the existing `if candidate:` condition invokes the `__bool__` magic method of the `Toggle` class from kopf.
Closes#36837
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36837 from mboutet:patch-1 831152ca47
PiperOrigin-RevId: 646539016
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37039
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37039 from tanvi-jagtap:large_file_01 d7705c0bf6
PiperOrigin-RevId: 646417700
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36942
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36942 from tanvi-jagtap:src_core_lb 524b45fef1
PiperOrigin-RevId: 646311061
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#37034
PiperOrigin-RevId: 646276954
Originally when I was implementing call-v3 I added async handling for server trailing metadata because it was symmetrical with all the other handling we had. Turns out that we really don't need this, and further it's probably harmful to our ability to reason about the stack - so I'm removing that capability.
Closes#36984
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36984 from ctiller:no-infallible-seq f3b3548685
PiperOrigin-RevId: 646146666
Updates to channel init registration ordering:
* Add ability to float filters towards the top of the stack or to sink them towards the bottom. This is a secondary hint to the explicit ordering constraints that we have. To avoid possible ambiguities we enforce that there can never be two tops/two bottoms available to add simultaneously (if this eventuality appears we simply require an explicit ordering between the two filters).
* Add the ability to skip some filters in the V2 stack (so we can start building V3 only filters)
Along the way:
* Add hashability to `UniqueTypeName`
* Remove `UniqueTypeName` copy constructor (this is just the default copy constructor anyway, and its presence started to confuse `clang-tidy`).
* Separate the dependency tracking and logging parts of channel_init.cc. This was necessary for my brain to be able to process how to implement the new ordering constraints. Happily, it also eliminates an O(n**2) loop in initialization!
Closes#36993
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36993 from ctiller:ordering-innit e9d08e7a81
PiperOrigin-RevId: 646144240
Creating a new PR in continuation to #36894 to fix post-submit errors. I've re-added the `from ._metadata import Metadata` statement to fix the post-submit error.
Closes#37022
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37022 from sreenithi:fix-issues/36613 beb5b5c63d
PiperOrigin-RevId: 646142324
There's some tooling floating around that looks for `BM_` prefixed strings and was failing with these benchmarks.
Re-jiggle some macros around so that's no longer the case.
Closes#37024
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37024 from ctiller:bm- 9b2fc76807
PiperOrigin-RevId: 646137939
[Gpr_To_Absl_Logging] Remove gpr_log_severity_string
This function is not getting used anymore gpr_log_severity_string
Closes#37013
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37013 from tanvi-jagtap:gpr_log_severity_string_remove 3346face4c
PiperOrigin-RevId: 645796077
When starting a call, we could delete the transport before acquiring the party lock for the call handler, leading to a use-after-free.
Closes#37019
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37019 from ctiller:chaotic-bug 58254aa19c
PiperOrigin-RevId: 645542043
It looks like this duplicate was accidentally added several years ago during a revert of a revert.
Closes#37020
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37020 from matthewstevenson88:alts-dup d0578c48f3
PiperOrigin-RevId: 645541373
As we've learned what configuration is needed for our benchmarks the settings have been growing more and more bespoke for each binary. Try to consolidate that into some useful defaults.
Also ensure we always `linkstatic=1`. `cc_binary` defaults to this, so it's reasonable to assume that's the performance our customers see. It also deeply impacts performance for small microbenchmarks, and so enabling it gives us more apples:apples, and saves chasing things that don't matter.
Closes#37012
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37012 from ctiller:benchmark-bin b84cab58c6
PiperOrigin-RevId: 645483183
Previously, metadata mutations were made by the picker directly, which meant that they would be applied even if the channel winds up discarding the pick due to the returned subchannel having been disconnected by the time the pick result is returned. This changes the API such that pickers return metadata mutations along with the pick result, so that the mutations won't get applied unless the pick result is actually used.
Closes#36968
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36968 from markdroth:lb_metadata_api 2765da6121
PiperOrigin-RevId: 645451869
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36979
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36979 from tanvi-jagtap:src_core_util a160d9d7ec
PiperOrigin-RevId: 645397740
[Gpr_To_Absl_Logging] Cleaning up the allow list for deprecated functions.
This file has a list of deprecated functions.
Any new instance of a deprecated function being used in the code will be flagged by the script. If there is a new instance of a deprecated function in a Pull Request, then the Sanity tests will fail.
We are currently working on clearing out the usage of deprecated functions in our code base.
For that reason, while our cleaning is in progress we have a temporary allow list. The allow list has a list of files where clean up of deprecated functions is pending. As we clean up the deprecated function from files , we will remove them from the allow list.
Ideally, it would be wise to do the file clean up and the altering of the allow list int the same PR. This will make sure that any roll back of a clean up PR will alter the allow list and avoid build failures.
Closes#36977
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36977 from tanvi-jagtap:clean_allow_list_2024_06_19 9393244cee
PiperOrigin-RevId: 645325296
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36883
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36883 from tanvi-jagtap:large_file_01 43eb4880cf
PiperOrigin-RevId: 645281490
Updated the type hint for return type of grpc.aio.ServicerContext.invocation_metadata() to Optional[MetadataType] instead of Optional[Metadata].
MetadataType is already defined to be a Sequence[MetadatumType] and hence the type hint will reflect the sequence being returned, hence solving the [user's reported issue](https://github.com/grpc/grpc/issues/36613)
Closes#36894
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36894 from sreenithi:fix-issues/36613 7d3a047309
PiperOrigin-RevId: 645276778
[Gpr_To_Absl_Logging] Removing incorrect entry from Sanity test
For now - we have decided to continue to keep this function.
So I am removing it from this list.
Closes#36987
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36987 from tanvi-jagtap:gpr_log_verbosity_init_removal cbfb969f34
PiperOrigin-RevId: 645274187
When building #36946 I noticed a bunch of places where `GetContext<>` was not inlined. This change forcibly inlines paths that we need to be, and additionally lowers the `CHECK` in `GetContext` to be a `DCHECK` as this comparison was using the bulk of the time in a very hot function in the stack.
Closes#36970
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36970 from ctiller:dcheckctx 28a779899d
PiperOrigin-RevId: 645202335
This commit implements `logger=` for GRPC module. It will allow us to inject a custom logger on the fly easily. Using `self.extend` inside this setter will help us deal with backward compatible for some custom Logger Module.
<!--
Your pull request will be routed to the following person by default for triaging.
If you know who should review your pull request, please remove the mentioning below.
-->
Fixed#24084
cc @sampajano , @apolcyn and @alto-ruby TIA
re: https://github.com/grpc/grpc/pull/24072Closes#36989
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36989 from nvh0412:chore/add-logger-setter-for-GRPC-ruby-2 f5a91225e7
PiperOrigin-RevId: 645189146
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#36901
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36901 from yijiem:ares-windows-fix 7c16a8a741
PiperOrigin-RevId: 645182157
These are substitutes for language features and never warrant a new function being created. Significantly boosts the benchmarks in #36946Closes#36981
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36981 from ctiller:seqqy 1a075be7e9
PiperOrigin-RevId: 645169296
…_serializer_dispatch
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#36997
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36997 from yousukseung:work-serializer-dispatch c8976c4f02
PiperOrigin-RevId: 645153599
### Problem 1
Context :
gpr_log() internally calls gpr_log_message() .
gpr_log_message() may either call gpr_default_log() or a user provided logging function.
gpr_default_log() uses absl LOG. This is the default. Most users will log this way.
For the small percentage of users who have customized the logging function, gpr_log will log to custom this function.
Problem :
We have converted half the instances of gpr_log to absl LOG().
For users who use the defaults - there will be no issue.
For the users who use a customized logging function
1. All the absl LOGs will log to the absl log sink.
2. All the gpr_log statements will log via this user provided function.
This is in-consistent behaviour and will cause confusion and difficulty in debugging.
Solution:
All logs should go to the same sink.
So we decided to make gpr_set_log_function a no op in this release.
The function will be deleted in the next release.
https://github.com/grpc/proposal/pull/425
### Problem 2
Context :
gpr_should_log is used to avoid computing expensive stuff for logging if the log is not going to be visible.
Problem :
gpr_should_log was referencing the GRPC_VERBOSITY flag and values set by gpr_set_log_verbosity .
However, actual logging happens based on the absl settings.
This is incorrect. Because if the old settings are not honoured, they should not be checked and no decision in code should be made based on settings which are not going to get used.
Solution :
Given the above changes in Problem 1, since all custom logging is disabled, all logging from gRPC with honour the absl LOG settings. Hence we modified the gpr_should_log function to refer to absl settings.
### Problem 3
We still have the issue of php using a custom log sink. We will address this in a separate PR.
### Problem 4
Tests related to test/core/end2end/tests/no_logging.cc are broken . These will be fixed in another PR.
Closes#36961
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36961 from tanvi-jagtap:fix_gpr_should_log 70c3224af1
PiperOrigin-RevId: 645096418
In the client fuzzer, some valid fuzzing scenarios would close the transport (thus deleting the endpoint), while the fuzzer mechanics still attempted to read/write to that endpoint. There was an inherent ownership problem, where both the transport and the fuzzer logic expected to own the endpoint lifetime.
This PR ensures that the transport owns the endpoint, and the fuzzer logic owns an object that can write to some shared endpoint state. This shared object can outlive the endpoint.
Closes#36966
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36966 from drfloob:fuzzer/4908841560506368 a9ea2e795d
PiperOrigin-RevId: 645081665
[Gpr_To_Absl_Logging] Remove custom logger from php. Not supported anymore.
While I am writing a custom absl LogSink to fix the issue in the next Pull Request,
I wanted to know if not having this LogSink is a release blocker or not.
Closes#36962
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36962 from tanvi-jagtap:fix_php_logging 1374cbc838
PiperOrigin-RevId: 645056513
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36980
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36980 from tanvi-jagtap:src_core_lib_promise_filter 19ed6234f4
PiperOrigin-RevId: 645050090
Specifically:
- use `OrphanablePtr<>` for `grpc_endpoint`
- use `absl::AnyInvocable<>` instead of `grpc_closure`
- use `EventEngine::Run()` instead of `ExecCtx::Run()`
- use `SliceBuffer` instead of `grpc_slice_buffer`
- use `absl::Status` instead of `grpc_error_handle`
- use `absl::string_view` instead of `const char*` for handshaker names
Also pass acceptor via `HandshakerArgs` instead of as a separate parameter.
Also changed chttp2 and httpcli to use `OrphanablePtr<>` for the endpoint.
PiperOrigin-RevId: 644551906
Easwar Swaminathan
Craig Tiller
Maxence Boutet
Tanvi Jagtap
Tanvi Jagtap
Yijie Ma
Mark D. Roth
Sreenithi Sridharan
Yash Tibrewal
Matthew Stevenson
AJ Heller
apolcyn
Hoa Nguyen
Yousuk Seung