Click house/v1.57.1 #35
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<!-- 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. -->
The approach of doing a recursive function call to expand the if checks for known metadata names was tripping up an optimization clang has to collapse that if/then tree into an optimized tree search over the set of known strings. By unrolling that loop (with a code generator) we start to present a pattern that clang *can* recognize, and hopefully get some more stable and faster code generation as a benefit. <!-- 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. --> --------- Co-authored-by: ctiller <[email protected]>
Fix for Cython build issue in aarch64.
We're seeing this error in aarch64 distribution test:
```
In file included from ./src/core/lib/slice/slice.h:36,
from ./src/core/lib/slice/slice_buffer.h:29,
from ./src/core/lib/transport/transport.h:60,
from ./src/core/lib/channel/channel_stack.h:75,
from ./src/core/lib/channel/call_tracer.h:32,
from src/python/grpcio/grpc/_cython/cygrpc.cpp:2230:
./src/core/lib/slice/slice_refcount.h: In member function 'void grpc_slice_refcount::Ref(grpc_core::DebugLocation)':
./src/core/lib/slice/slice_refcount.h:55:25: error: expected ')' before 'PRIdPTR'
"REF %p %" PRIdPTR "->%" PRIdPTR, this, prev_refs, prev_refs + 1);
^~~~~~~~
)
```
Based on [this
post](https://stackoverflow.com/questions/26182336/priuptr-preprocessor-bug-in-gcc),
it's caused by including `<inttypes.h>` before define
`__STDC_FORMAT_MACROS` marco.
`<inttypes.h>` was included in `core/lib/channel/call_tracer.h` and this
macro should already be defined in `grpc/grpc.h` through
`port_platform.h`, but we're still having issue in aarch64, so we
manually define the macro in this PR.
Revert "Revert "[core] Add support for vsock transport" (grpc/grpc#33276)" This reverts commit grpc/grpc@c5ade30. And fix the issue which broke the python build. @markdroth @drfloob please review this PR. Thank you very much. --------- Co-authored-by: AJ Heller <[email protected]>
<!-- 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. -->
<!-- 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. -->
…33379) This reverts #32973 that causes breakages in internal CI.
… (#33360)
Do not clutter the final error we see at the end with the before/after
stats.
#### Examples
###### Expected only status A, but found status B for method M:
```
[ FAILED ] CustomLbTest.test_custom_lb_config
======================================================================
FAIL: test_custom_lb_config (__main__.CustomLbTest)
CustomLbTest.test_custom_lb_config
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/sergiitk/Development/grpc/tools/run_tests/xds_k8s_test_driver/tests/custom_lb_test.py", line 113, in test_custom_lb_config
self.assertRpcStatusCodes(test_client,
File "/Users/sergiitk/Development/grpc/tools/run_tests/xds_k8s_test_driver/framework/xds_k8s_testcase.py", line 345, in assertRpcStatusCodes
found_status = helpers_grpc.status_from_int(found_status_int)
AssertionError: Expected only status (15, DATA_LOSS), but found status (0, OK) for method UNARY_CALL.
Diff stats:
- method: UNARY_CALL
rpcs_started: 251
result:
(0, OK): 251
```
###### Expected non-zero RPCs with status A for method M.
```
[ FAILED ] AuthzTest.test_plaintext_allow
======================================================================
FAIL: test_plaintext_allow (__main__.AuthzTest)
AuthzTest.test_plaintext_allow
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/sergiitk/Development/grpc/tools/run_tests/xds_k8s_test_driver/tests/authz_test.py", line 224, in test_plaintext_allow
self.configure_and_assert(test_client, 'host-wildcard',
File "/Users/sergiitk/Development/grpc/tools/run_tests/xds_k8s_test_driver/tests/authz_test.py", line 204, in configure_and_assert
self.assertRpcStatusCodes(test_client,
File "/Users/sergiitk/Development/grpc/tools/run_tests/xds_k8s_test_driver/framework/xds_k8s_testcase.py", line 355, in assertRpcStatusCodes
self.assertGreater(stats.result[expected_status_int],
AssertionError: 0 not greater than 0 : Expected non-zero completed RPCs with status (0, OK) for method EMPTY_CALL.
Diff stats:
- method: EMPTY_CALL
rpcs_started: 13
result: {}
```
…eout risk (#33387) Also drop a few deadlines so that tests can run faster (where that's safe) <!-- 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. -->
There is potential for a long shutdown process under load (seconds instead of milliseconds).
~Something about the additional load from #33374 has caused some entirely unrelated ios tests to fail sporadically. I'd prefer not to roll back that however as it's discovered real bugs that had been previously masked.~ These tests have been failing sporadically for some time. We can track these on the daily flakiness reports, but whilst we investigate let's just universally mark them as flaky so we don't confuse folks trying to submit.
`cmake_ninja_vs2019` and `default` are using the same `cmake_ninja_vs2019` so having two tests are waste so this is removing `cmake_ninja_vs2019` leaving `default` which does `cmake_ninja_vs2019`. This change can cut the space consumption by half and with 250GB disc, - Pre-test: 267,770,322,944 bytes free - Post-test: 134,499,295,232 bytes free
The function grpc_rb_server_request_call has many places that could raise errors, including in child functions. Since a raised error will longjump out of the function, it will cause memory leaks since the function cannot perform any clean up. This commit fixes the issue by wrapping the whole function in an rb_ensure, which will ensure that a cleanup function is ran before the error is propagated upwards.
The function grpc_rb_call_run_batch has many places that could raise errors, including in child functions. Since a raised error will longjump out of the function, it will cause memory leaks since the function cannot perform any clean up. This commit fixes the issue by wrapping the whole function in an rb_ensure, which will ensure that a cleanup function is ran before the error is propagated upwards.
Reverts grpc/grpc#33385 Temporary revert to unblock grpc/grpc#33138
- Switched from yapf to black - Reconfigure isort for black - Resolve black/pylint idiosyncrasies Note: I used `--experimental-string-processing` because black was producing "implicit string concatenation", similar to what described here: psf/black#1837. While currently this feature is experimental, it will be enabled by default: psf/black#2188. After running black with the new string processing so that the generated code merges these `"hello" " world"` strings concatenations, then I removed `--experimental-string-processing` for stability, and regenerated the code again. To the reviewer: don't even try to open "Files Changed" tab 😄 It's better to review commit-by-commit, and ignore `run black and isort`.
Fix #33308 <!-- 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. -->
PR #33138 is the Large Scale Change in which python style is changed from yapf to black. Nearly all python files were reformatted. This PR configures git clients supporting `.git-blame-ignore-revs` feature to show the original author in `git blame`. Details: https://black.readthedocs.io/en/stable/guides/introducing_black_to_your_project.html GitHub uses this feature by default: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view Local git clients can enable this feature with `git config blame.ignoreRevsFile .git-blame-ignore-revs`.
Timers are not run on cancellation.
Here the recv message batch 103 was returning end of stream. Per the reasoning in https://github.com/grpc/proposal/blob/master/L104-core-ban-recv-with-send-status.md Sending status is the final thing for a call on the server, so requiring a recv message to complete when we've sent status is getting into at best a gray area in out spec. Add a strict ordering between that recv and the sending of status to make a more deterministic test. fixes b/286708835, b/286727273
…407) Fixes b/286780969
Maintainers being moved to emeritus status - * @dapengzhang0 * @medinandres * @Vizerai * @yihuazhang * @ZhenLian If there are no disagreements, this PR will be merged on May 24, 2023 as per https://github.com/grpc/grpc-community/blob/main/governance.md#losing-maintainer-status <!-- 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. -->
…3404) Fixes internal fuzzing bug b/286717107
With some delay, this is a PR for grpc/grpc#32564 (and previously grpc/grpc#31791). I looked into adding a regular `py_test` for this change [as suggested](grpc/grpc#31791 (comment)) but I am not aware of any effect that the presence of a .pyi stub file would have at runtime and where some sort of type-checking in a .py script would be affected. Stub files are only for use by type checkers & IDE's. I mean, something like this would work: ``` import helloworld_pb2 py_file = helloworld_pb2.__file__ pyi_file = py_file + 'i’ self.assertTrue(os.path.exists(pyi_file)) ``` But that seems really hacky to me. Instead I created a simple rule test for `py_proto_library` with Bazel Skylib which tests the declared outputs for an example `py_proto_library` target. Indirectly, this also tests that the declared output files are actually generated. Please let me know if this is sufficient.
(needed to unblock promises rollout)
Unblocks promises rollout
… to the app (#33782) Promises code can prevent these bad requests from even reaching the application, which is beneficial but this test needs a minor update to handle it. --------- Co-authored-by: ctiller <[email protected]>
As title - use a deadline that rules out starvation as a source of flakiness
…after free (#33780)
This test appears to be timing out more often lately. Example: https://fusion2.corp.google.com/ci/kokoro/prod:grpc%2Fcore%2Fpull_request%2Flinux%2Fbazel_rbe%2Fgrpc_bazel_rbe_ubsan/activity/980ac4a8-da71-4b9b-838e-e9ea235820a1/log
…ng grpc (#33788) Should fix grpc/grpc#33787
Fixes b/282107030 I tested this locally by building the images and running some PSM interop tests.
The case of `!grpc_ruby_initial_pid()` can be a *cause* of the second case, `!grpc_ruby_initial_thread`, so check the pid first.
We are seeing `g++: fatal error: Killed signal terminated program cc1plus` on PHP distribtest builds. In case it's an OOM, let's try reducing the build parallelism to see if it helps.
Change was created by the release automation script. See go/grpc-release
…rt) (#33806) Backport of #33796 to v1.57.x. --- grpc/grpc#33699 incorrectly changed the legacy builds to not just use the test driver from the master, but also to build from it. This PR fixes the issue, and also updates the python job to work use the driver from master.
Change was created by the release automation script. See go/grpc-release
Related to grpc/grpc#33795. The tests are still OOMing, and I found that this distribtest script is still running `make -j ...` on a 16-core machine. Reducing it to `8` to see if that helps. Example OOM: https://fusion2.corp.google.com/invocations/c306e6b9-24e3-498d-8971-3e914feea29b/log
…wait logic that interferes with forking #33805" to v1.57.x (#33846) Backports #33805
Update Phusion base image to address security issues. Original PR: #33847
Change was created by the release automation script. See go/grpc-release
Change was created by the release automation script. See go/grpc-release
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.