<!--
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.
-->
New versions of Clang (and GCC) warn about this
grpc_authorization_policy_provider.cc:124:17: error: format specifies
type 'int' but the argument has type 'absl::StatusCode'
[-Werror,-Wformat]
124 | "authorization policy reload status. code=%d error_details=%s",
| ~~
125 | status.code(), std::string(status.message()).c_str());
In chttp2: a pending but not yet sent goaway should block incoming
requests just like a sent one (we will sent that data momentarily!)
In the test:
- handle the case of the connection idle timeout happening before the
request arrives at the server
- disable retries, as these cause the request to get stuck (as we don't
have an additional server to retry on)
Fix b/287897932
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
Noticed some inconsistencies in our keepalive configuration -
* Earlier, even if keepalive pings were disabled, we would be scheduling
keepalive pings at an interval of INT_MAX ms.
* We were not using `g_default_client_keepalive_permit_without_calls` /
`g_default_server_keepalive_permit_without_calls`. They are both false
by default but they can be overridden in
`grpc_chttp2_config_default_keepalive_args`.
<!--
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.
-->
Child classes of polling resolvers might have use cases where they would want to request a resolution explicitly which honor the min time between requests. As RequestReresolutionLocked needs to be called in from work_serializer which is usually owned by polling resolver completely, allow passing the work serializer back to the child class.
It is not uncommon for Android tests to fail due to an NDK download
failure. To address this issue, the Android Docker image has been
updated to include NDK and CMake. This will help to avoid download
problem.
I verified this works as intended to see the invocation log not having
installation log for NDK and CMake such as
```
Checking the license for package NDK (Side by side) 25.1.8937393 in /opt/android-sdk/licenses
License for package NDK (Side by side) 25.1.8937393 accepted.
Preparing "Install NDK (Side by side) 25.1.8937393 (revision: 25.1.8937393)".
"Install NDK (Side by side) 25.1.8937393 (revision: 25.1.8937393)" ready.
Installing NDK (Side by side) 25.1.8937393 in /opt/android-sdk/ndk/25.1.8937393
"Install NDK (Side by side) 25.1.8937393 (revision: 25.1.8937393)" complete.
"Install NDK (Side by side) 25.1.8937393 (revision: 25.1.8937393)" finished.
Checking the license for package CMake 3.10.2.4988404 in /opt/android-sdk/licenses
License for package CMake 3.10.2.4988404 accepted.
Preparing "Install CMake 3.10.2.4988404 (revision: 3.10.2)".
"Install CMake 3.10.2.4988404 (revision: 3.10.2)" ready.
Installing CMake 3.10.2.4988404 in /opt/android-sdk/cmake/3.10.2.4988404
"Install CMake 3.10.2.4988404 (revision: 3.10.2)" complete.
"Install CMake 3.10.2.4988404 (revision: 3.10.2)" finished.
```
We want writes to participate in event re-ordering, but it's unlikely
that we can sustain one byte per 500ms on all tests and keep them
passing (which is the degenerate case right now).
Tune write delays down to 50ms for the moment, though I expect we'll
want to talk about going lower.
omgwtfbbq
This test relies on WAIT_FOR_READY semantics, but we don't do that in
the proxy, so it got assigned the wrong suite.
Fix the suite, fix the flakes.
Also add some handy dandy logging to help figure this stuff out in the
future.
In rare cases across gRPC's end2end tests (only in Windows RBE with
debug builds, interestingly enough), the endpoint may be destroyed
before the final IOCP read callback has run. This edge case is only
triggered when all the following are true:
* the previous read operation received data (not an error, not
0-length), so more data is expected in the stream.
* the socket has not yet shut down
* the application destroyed its endpoint before (or during) the IOCP
callback execution.
* the Read operation has not yet called the client's on_read callback.
This is a valid scenario, and it is expected that the engine
implementation should call the application callbacks with error statuses
when this occurs. This PR fixes two associated bugs.
I can still make the old algorithm break and assign duplicate names on
my machine... make it a little more robust.
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
I've had local runs with a 10 second gap between creating the call and
issuing the first batch client side.
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
Previously we were running these at call termination, but internally we
have things that want to access finalizer cleaned up data after that
point.
<!--
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.
-->
This is a no-op, just reordering `requirements.lock`.
By providing `-r requirements.txt` to `pip freeze` it's able to break up
dependencies required via `requirements.txt`, and sub-dependencies
installed to satisfy them.
[requirements.bazel.txt] :updating wheel package to 0.38.1 to fix the
vulnerability
input: lang/python
release notes: no
settings: release notes:no
updating wheel package to 0.38.1 to fix the vulnerability
#python
please do fix it quickly
<!--
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.
-->
Fix fuzzer found bug b/286716972
Follows up on https://github.com/grpc/grpc/pull/33266 but gets the edge
case right of when there's a read queued before the peer closes - in
that case we weren't waking up the read.
I've got a hypothesis that we're losing isolation between test shards
right now for "some reason".
This is a change to reflect test sharding in the port distribution that
we use, in an attempt to alleviate that.
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
Moritz
Eugene Ostroukhov
Yash Tibrewal
Sergii Tkachenko
Benjamin Kramer
Craig Tiller
Yuriy Chernyshov
Ming-Chuan
Anirudh Ramachandra
Mark D. Roth
Esun Kim
AJ Heller
suryadev99
April Kyle Nassi