We've seen some recent crashes with the work_serializer_dispatch experiment where the picker is null when we try to do an LB pick. The only code-path we've found where the picker is set to null is the one triggered by the channel_idle filter, so we think we may be hitting a race condition where the call is started on the client_channel filter after the request to go idle has hit the WorkSerializer but before it has actually run.
If that is the cause, then the right fix is to ensure that once we dispatch the request to go idle, we enqueue any subsequent RPC and dispatch a request to exit idle. However, that will require a bit of work, and it will be easier to do as part of the new call v3 channel stack, so we don't want to invest time in fixing this in the current implementation.
For now, we add a work-around where we fail the RPC if the picker is null, which is better than crashing but not ideal.
Closes#36167
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36167 from markdroth:client_channel_idle_race_workaround 0207dd3bdd
PiperOrigin-RevId: 618271781
#35923 removed the use of mach_absolute_time in gpr.
There is still one usage in protobuf, which they have removed the usage in https://github.com/protocolbuffers/protobuf/pull/15554 but we haven't update yet.
However gRPC library does not depends on protobuf but upb, so we should no longer need NSPrivacyAccessedAPICategorySystemBootTime any more.
Closes#36080
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36080 from HannahShiSFB:remove-privacy-for-mach_absolute_time dacccafeec
PiperOrigin-RevId: 617995787
These two things are different (event engine being a context has nothing to do with the ability to get a default event engine).
Lumping them into the same header means that things that want the context also need to want the default event engine declarations, which in turn pull in CoreConfiguration -- which ultimately means that nothing that is depended on by CoreConfiguration can consume the event engine context, which is undesirable (and causing dependency loops in current work).
Also includes an impressive number of cleanups to `grpc_base` because I ran `fix_build_deps` on that target as part of this.
Closes#36148
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36148 from ctiller:context-isnt-default--default-isnt-context a4fdad9621
PiperOrigin-RevId: 617961015
Adding testing for `Size()` on `MeshLabelsIterable` as promised on https://github.com/grpc/grpc/pull/35371
This method doesn't get used the OTel C++ library at present so it was untested earlier, and bugs in its implementation were noticed later. To avoid that issue in the future, adding manual testing of this method.
Changes -
* Moved `MeshLabelsIterable` to the header to be able to test its Size method directly. Also had to move around some internals to be able to do so.
* Replaced `absl::variant<grpc_core::Slice, StructPb> metadata_` from decoding the metadata lazily to just decoding it in the constructor. I don't remember the original thinking behind this. Maybe I wanted the decoding to happen lazily, but there doesn't seem to be much gain from doing it lazily, we instead have to deal with the overhead of `variant`.
Closes#35769
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35769 from yashykt:CsmMeshLabelsIterableSizeTesting ec9033b742
PiperOrigin-RevId: 617901839
I was surprised to see that the C++ core interprets "grpc-accept-encoding: deflate" like HTTP: it compresses messages using zlib with deflate compression, rather than using raw deflate. Matching HTTP semantics makes sense, of course, but this misnomer has historically confused HTTP implementations too.
This detail didn't seem important enough to warrant inclusion in the main protocol specification, so I've proposed an addition to `docs/compression.md` to document the expected behavior. I'm happy to move the addition around if you'd prefer it elsewhere.
Closes#36113
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36113 from akshayjshah:deflate 9177d39d63
PiperOrigin-RevId: 617635558
<!--
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#36131
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36131 from yijiem:no-logging f3f638176f
PiperOrigin-RevId: 617630514
Reproduced with :
- bazel-bootstrap 3.5.1+ds-3 (pulling bazel 6.4.0)
- setting CC to gcc and CXX to g++ otherwise bazel does not detect it
- overall, using debian 11 using default gcc/g++ versions 10.2.1
When using --config=dbg, a warning name produces an error at the beginning of the compilation :
`cc1plus: error: '-Werror=return-stack-address':
no option '-Wreturn-stack-address';
did you mean '-Wreturn-local-addr'?`
Fixed the error following the compiler advice for GCC
PLEASE NOTE : I guess `return-stack-address` might be related to CLANG
and `return-local-addr` is the GCC equivalent. I do not know CLANG,
nor am i good enough with bazel to know how to make this option flexible
(so any help will be appreciated)
Closes#36040
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36040 from nipil:fix_compile_dbg_option 7ade99de76
PiperOrigin-RevId: 617281605
This commit does the following 3 things for Android bazel rules, which depends on each other
1. Update NDK to 26.2.11394342 (and a few other Android things)
2. Use rules_android_ndk instead of builtin `native.android_ndk_repository`
* `third_party/android/android_configure.bzl` was a workaround for users who don't set `$ANDROID_NDK_HOME` env var. Now with rules_android_ndk, we can declare repo without registering the toolchain. Instead users who need NDK toolchain should use `--extra_toolchains` to manually register the toolchain, as shown in README.md.
3. Migrate to platforms. See https://bazel.build/concepts/platforms
* Currently we declares android platforms that is needed for binder transport APK. Later gRPC repo can gradually migrate to platforms for other platforms.
* The value of `crosstool_top` will still be `//external:android/crosstool` (which is the default value), so existings android `config_settings` will still work. We should migrate them to match with `@platforms//os:android` constraint later.
The platforms migration needs Bazel 7.0 to work so we also override bazel version in testing scripts.
Closes#36116
PiperOrigin-RevId: 617244655
If party1 wakes party2 we'd prefer that party1 finishes all its activations before it wakes party2:
intuition: party1 might wake party2 for other things too, and being able to coalesce them all into one wakeup significantly helps performance.
Closes#36048
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36048 from ctiller:wakey f6d4416685
PiperOrigin-RevId: 616970833
Channel target will now be reported in canonified form (e.g., in channelz).
Closes#36134
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36134 from markdroth:channel_target 22e49e73f8
PiperOrigin-RevId: 616911536
Fix the wording of the description of the function for the return value : current version says the opposite of what the function does. The current behaviour is to return the port used, but only when the address _is actually_ a wildcard address : 0.0.0.0 (ipv4) or :: (ipv6). Plus mention both ipv4 and ipv6 in the description.
Closes#36143
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36143 from nipil:fix_ResolvedAddressIsWildcard_doc 70683d0139
PiperOrigin-RevId: 616894483
There were some failures in the Crl Directory related tests after https://github.com/grpc/grpc/pull/36031
This came down to https://github.com/grpc/grpc/pull/36031 adding some CRLs with bad qualities (invalid content/signatures, overriding issuer names) to the `test_creds/crl_data/crls` directory, which is used in the directory reloading tests. The tests began failing on some platforms because they were picking up these bad crls which were failing various checks, but the test was designed to assume that `test_creds/crl_data/crls` was a valid and good directory.
This PR moves the bad CRLs to their own directory to prevent this accidental mash-up of test data. It also adds debug logging to our custom verification stack.
Closes#36122
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36122 from gtcooke94:crl_fix 508dd1370d
PiperOrigin-RevId: 616280898
This is a prerequisite for the upcoming Protobuf v26 upgrade and has the following changes;
- Reduced the optimization level from `O3` to `O1` on Linux to workaround a segfault issue on `manylinux2014/x86`. This is believed to be caused by an aggressive but buggy optimization that `gcc` 10 made so workaround is to reduce the optimization level. `gcsio_tools` isn't that performance sensitive so we should be able to afford this change. (internal b/329134877)
- Added a Windows library dependency `Shell32.lib` to support the use of `CommandLineToArgvW`. (internal b/328455319)
Closes#36124
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36124 from veblush:grpcio-x e7b555bfcf
PiperOrigin-RevId: 616245600
Ref: https://bugs.ruby-lang.org/issues/20311
C global variable that contain references to Ruby object MUST be declared to the Ruby GC to prevent these objects from being collected or moved.
There are a few exceptions to that, such as classes defined using the C APIs such as `rb_define_class` etc.
Up to Ruby 3.4 however, there was a bug that caused classes created from Ruby with the `Struct.new("Name")` API to also be marked as immortal and immovable.
GRPC has been relying on this bug, which I fixed in Ruby 3.4, and now GRPC is crashing when `Struct::Status` is moved around by the GC.
```
-- C level backtrace information -------------------------------------------
ruby(rb_print_backtrace+0x14) [0x5577db219d41] ruby-3.4.0/vm_dump.c:820
ruby(rb_vm_bugreport) ruby-3.4.0/vm_dump.c:1151
ruby(rb_bug_for_fatal_signal+0xfc) [0x5577db3cc60c] ruby-3.4.0/error.c:1066
ruby(sigsegv+0x4d) [0x5577db16358d] ruby-3.4.0/signal.c:926
libc.so.6(0x7f5bacd32520) [0x7f5bacd32520]
ruby(rb_class_superclass+0x32) [0x5577db0a9152] ruby-3.4.0/object.c:2239
ruby(struct_ivar_get+0x2a) [0x5577db194e02] ruby-3.4.0/struct.c:49
ruby(struct_ivar_get) ruby-3.4.0/struct.c:40
ruby(num_members) ruby-3.4.0/struct.c:705
ruby(rb_struct_new+0x56) [0x5577db19a9d6] ruby-3.4.0/struct.c:848
lib/grpc/grpc_c.so(grpc_run_batch_stack_build_result+0xe6) [0x7f5b84bb6b96] /tmp/bundle/ruby/3.4.0+0/bundler/gems/grpc-5ed33ee673e3/src/ruby/ext/grpc/rb_call.c:780
lib/grpc/grpc_c.so(grpc_rb_call_run_batch_try) /tmp/bundle/ruby/3.4.0+0/bundler/gems/grpc-5ed33ee673e3/src/ruby/ext/grpc/rb_call.c:839
ruby(rb_ensure+0x10c) [0x5577db007d3c] ruby-3.4.0/eval.c:1000
/tmp/bundle/ruby/3.4.0+0/bundler/gems/grpc-5ed33ee673e3/src/ruby/lib/grpc/grpc_c.so(grpc_rb_call_run_batch+0xca) [0x7f5b84bb595a] /tmp/bundle/ruby/3.4.0+0/bundler/gems/grpc-5ed33ee673e3/src/ruby/ext/grpc/rb_call.c:893
ruby(vm_call_cfunc_with_frame_+0x117) [0x5577db1f4c77] ruby-3.4.0/vm_insnhelper.c:3524
```
cc @apolcyn@peterzhu2118@k0kubunCloses#36125
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36125 from Shopify:fix-ruby-3.4-compat 7a127599c8
PiperOrigin-RevId: 616152904
Address comments from design review meeting, mainly:
* Use `OpenTelemetryPlugin` as public API.
* Use keyword args to build plugin.
<!--
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#36094
PiperOrigin-RevId: 615807264
The stubs generated by grpcio_tools should always be used with [the same or higher version of grpcio](https://github.com/grpc/grpc/blob/master/tools/distrib/python/grpcio_tools/setup.py#L313), this change will add a run time check for this requirement inside the generated stubs and therefor enforce this requirement.
Please note for now we're just printing a warning for incorrect usage, we'll **change it to an error** soon.
Example warning message:
```
/usr/local/google/home/xuanwn/workspace/misc/grpc/examples/python/helloworld/helloworld_pb2_grpc.py:21: RuntimeWarning: The grpc package installed is at version 1.60.1, but the generated code in helloworld_pb2_grpc.py depends on grpcio>=1.63.0.dev0. Please upgrade your grpc module to grpcio>=1.63.0.dev0 or downgrade your generated code using grpcio-tools<=1.60.1. This warning will become an error in 1.64.0, scheduled for release on May 14,2024.
```
<!--
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#35906
PiperOrigin-RevId: 615659471
Earlier, the tests just had bazel support. With CMake support added in #36063, we can also add CI CMake support for the tests. A major benefit of this is that we also get coverage for the various platforms that we test from our portability test suite.
Closes#36087
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36087 from yashykt:OTelCISupport b28fbe02e5
PiperOrigin-RevId: 615543685
<!--
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#36100
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36100 from yijiem:no-logging 970a640475
PiperOrigin-RevId: 615299752
This PR changes how CRLs are handled purely internally. After discussing with davidben@, there are various problems with the `X509_STORE_set_get_crl` API and we shouldn't use it. This change keeps the behavior and external API the same, but instead of bulk pushing CRL information into OpenSSL, we instead iterate through the built chain and check each certificate for revocation, as well as doing the CRL validation ourselves.
Closes#36031
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36031 from gtcooke94:CrlInternalRefactor 5f4c816648
PiperOrigin-RevId: 615139682
Refactored android-ndk docker image to have
- Replaced a full Android SDK with a Android command line tool (generally good for docker usage) and bumped its version to the latest among ones that support JDK 11
- Upgraded Debian from 10 to 11
- Upgraded Java SDK 8 to 11
- Upgraded Google CLI to the latest
Closes#36091
PiperOrigin-RevId: 615088973
Change was created by the release automation script. See go/grpc-release.
Additional Changes:
* Boring SSL started to [Require SSE2 when targetting 32-bit x86](56d3ad9d23), thus added `-msse2` to fix some build failures.
Closes#36089
PiperOrigin-RevId: 614822548
gRPC swift package depends on [boringSSL-SwiftPM](https://github.com/firebase/boringSSL-SwiftPM), which hasn't been updated since more than two years ago (https://github.com/firebase/boringSSL-SwiftPM/pull/8).
Updating it is not trivial as the `Package.swift` file is maintained manually, a recent [upgrade to swift 5.5](https://github.com/firebase/boringSSL-SwiftPM/pull/16) took good amount of time only to repeatedly exclude one (sometimes two) non-code files and retry build to get new errors, until the build succeeds.
This PR uses the gRPC build system to generate the swift package file from the same boringssl version in third_party.
Will use the output to update the boringSSL-SwiftPM repo after this PR is merged.
Tested with
```
cp BoringSSL-Package.swift Package.swift
swift build --target openssl_grpc
swift test
```
Closes#36062
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36062 from HannahShiSFB:add-boringssl-swift-package ac3e525bf2
PiperOrigin-RevId: 614088802
Yash Tibrewal
Mark D. Roth
AJ Heller
Hannah Shi
Craig Tiller
Esun Kim
Akshay Shah
Yijie Ma
Eugene Ostroukhov
Ming-Chuan Lin
nipil
Ming-Chuan
Gregory Cooke
Arvind Bright
Jean byroot Boussier
Vignesh Babu
Mike Kruskal
Xuan Wang
Tanvi Jagtap