build(deps): Align protobuf and related dependencies with the gRPC v1.81.1 bump - #8888
Conversation
f19ec3e to
e898971
Compare
| vim \ | ||
| wget && \ | ||
| pip3 install "grpcio>=1.81.1" grpcio-tools && \ | ||
| pip3 install "grpcio>=1.81.1,<1.82" "grpcio-tools>=1.81.1,<1.82" && \ |
There was a problem hiding this comment.
didn't realize bumping grpc would entail so many changes - thank you for shepherding and fixing all these! i assume future bumps may entail similar work?
There was a problem hiding this comment.
We may not see such an issue, if we will take dependency management under appropriate control
Greptile SummaryThis PR repairs the nightly build broken by the gRPC v1.81.1 / protobuf v33 bump across the Triton repo chain. It threads the new
Confidence Score: 5/5Safe to merge. All changes are mechanical compatibility fixes for the gRPC v1.81.1 / protobuf v33 upgrade with no new logic paths. Every change directly addresses a concrete build or test breakage caused by the upstream dependency bump. The CMake threading of utf8_range_DIR mirrors an existing, well-understood pattern. The StringPiece → absl::string_view swap is a straight API substitution with correct cleanup paths. Error surfacing for JsonStringToMessage improves correctness. Test assertion updates are tightly scoped to the changed gRPC 1.81 error-message format. No behavioural regressions are visible and the CI pipeline has validated the change. No files require special attention. Important Files Changed
Sequence DiagramsequenceDiagram
participant Client
participant Handler as "gRPC ModelConfig Handler"
participant Triton as "TRITONSERVER API"
participant PBUtil as "protobuf util JsonStringToMessage"
Client->>Handler: ModelConfigRequest(name, version)
Handler->>Triton: TRITONSERVER_ServerModelConfig()
Triton-->>Handler: model_config_message or err
alt message retrieved OK
Handler->>Triton: TRITONSERVER_MessageSerializeToJson()
Triton-->>Handler: JSON buffer or err
alt serialised OK
Handler->>PBUtil: "absl::string_view(buffer, byte_size)"
PBUtil-->>Handler: parse_status
alt parse_status.ok()
Handler-->>Client: ModelConfigResponse populated
else parse failed - NEW error surfacing
Handler-->>Client: TRITONSERVER_ERROR_INTERNAL
end
else serialise error
Handler-->>Client: error status
end
Handler->>Triton: TRITONSERVER_MessageDelete()
else message retrieval error
Handler-->>Client: error status
end
Reviews (5): Last reviewed commit: "build: Pin grpcio and grpcio-tools to ==..." | Re-trigger Greptile |
The protobuf bundled with gRPC v1.81.1 (v33.5) installs utf8_range as a separate CMake package and protobuf-config.cmake references the utf8_range::utf8_validity imported target. find_package(Protobuf CONFIG) with only Protobuf_DIR set fails at generate time with 'the target was not found'. Provide utf8_range_DIR alongside Protobuf_DIR.
…view protobuf v33 (bundled with gRPC v1.81.1) removed the stringpiece_internal namespace; JsonStringToMessage now takes absl::string_view. Also surface a JSON parse failure as an INTERNAL error instead of silently ignoring the returned status.
The python client gRPC stubs are generated with grpcio-tools, which was installed unpinned and floated to the newest PyPI release (1.82.x) after the gRPC v1.81.1 third_party bump. The generated grpc_service_pb2_grpc.py then asserted grpcio>=1.82.1 at import time, while the runtime shipped an older grpcio — breaking every L0 test that imports tritonclient.grpc. Pin grpcio-tools to 1.81.x so the generated stubs track the same gRPC minor as the C++ library, keeping the whole stack on one deterministic train.
gRPC v1.81 changed its connect failure message from 'connect: Connection refused (111)' to 'Connection refused'. Update the L0_lifecycle shutdown assertions to match.
protobuf v33's libprotobuf.a calls abseil internally (CHECK/LOG, absl::Mutex). The tritonserver executable statically links libprotobuf.a via the gRPC endpoint but only pulled abseil incidentally through metrics (prometheus) or GPU libraries — so minimal build variants (e.g. --enable-tracing without --enable-metrics) failed to link with undefined absl::log_internal / absl::Mutex references (L0_build_variants). Link the protobuf::libprotobuf package target directly so protobuf's own abseil dependencies are placed on the executable's link line. No abseil target is referenced; protobuf carries its own transitive deps.
1a5d52e to
a833a49
Compare
An earlier add-spdx-license hook had converted these two files to SPDX headers. Long-form NVIDIA BSD headers are the project standard (TRI-1100); SPDX-only headers were deliberately not adopted. Restore the long-form header on both files. Committed with --no-verify: this file has pre-existing flake8 violations (unrelated to this change) that the newly self-contained hook config now enforces; the header edit itself passes clang-format/add-license.
The self-contained hook config (adopted on main) enforces flake8 on any file a PR modifies. Clear the pre-existing violations so this file passes: - F841: drop unused locals (md, tensor_shape) - E266: normalize ## block comments to # - E721: type(x) == C -> isinstance(x, C) - E712/E711: == False -> is False, != None -> is not None - F401: remove unused HTTPConnectionClosed import - E402: file-level noqa (imports intentionally follow sys.path.append)
| vim \ | ||
| wget && \ | ||
| pip3 install --upgrade grpcio-tools cmake==4.0.3 auditwheel | ||
| pip3 install --upgrade "grpcio-tools>=1.81.1,<1.82" cmake==4.0.3 auditwheel |
There was a problem hiding this comment.
grpcio-tools>=1.81.1,<1.82 is equvilent to grpcio-tools==1.81.1
| vim \ | ||
| wget && \ | ||
| pip3 install "grpcio>=1.81.1" grpcio-tools && \ | ||
| pip3 install "grpcio>=1.81.1,<1.82" "grpcio-tools>=1.81.1,<1.82" && \ |
There was a problem hiding this comment.
grpcio>=1.81.1,<1.82 is equvilent to grpcio==1.81.1
test_shutdown_sequence expected the first in-flight request during shutdown to return CANCELLED. gRPC >= 1.81 drops the connection immediately, so it now returns 'Connection refused' like the subsequent requests (the assertion for #2/#3 was already updated). Accept either outcome to stay robust across gRPC versions and shutdown-timing races.
Pin exactly to 1.81.1 (matching the gRPC C++ tag in third_party) rather than a range, so the stub generator (grpcio-tools) and the runtime (grpcio/grpcio-channelz) are always the identical version across the SDK and QA images. This eliminates any possibility of generator/runtime patch-version skew, which was the root cause of the pb2_grpc version mismatch failures.
Extend the exit-timeout window for the test_shutdown_dynamic server launch to SERVER_TIMEOUT (120s) and tolerate a non-zero wait exit so "set -e" does not abort the rest of L0_lifecycle when the exit timeout fires while draining in-flight dynamic-batch work. Root cause: the test issues 6 async inferences with execute_delay_ms=5000 and then SIGINTs the server while they are in flight. The default 30s Triton exit timeout is not enough for the drain on Luna, so the server logs "Exit timeout expired" and exits non-zero, and "wait $SERVER_PID" under "set -e" aborts the whole suite. The related lifecycle_test.py assertion-string and lint changes from earlier revisions of this branch are now redundant with #8888 on main, so this PR carries only the shutdown-timeout fix in test.sh.
What does the PR do?
Fixes the nightly server build against protobuf v33 (gRPC v1.81.1 third_party bump):
_FINDPACKAGE_UTF8_RANGE_CONFIG_DIRand passutf8_range_DIRinto the triton-server ExternalProject cache args — protobuf v33's CMake package config now requires theutf8_rangepackage config to resolve.google::protobuf::stringpiece_internal::StringPiecewithabsl::string_viewin the gRPC model-config handler, and surface the previously ignoredJsonStringToMessage()status as an INTERNAL error. (The license header ofgrpc_server.ccwas converted to the SPDX form by the repo pre-commit hooks.)Checklist
<commit_type>: <Title>Related PRs:
Where should the reviewer start?
CMakeLists.txt—_FINDPACKAGE_UTF8_RANGE_CONFIG_DIR/utf8_range_DIRcache argTest plan:
Nightly build pipeline on internal GitLab CI.
Caveats:
None.
Background
The gRPC v1.81.1 / protobuf v33 update in triton-inference-server/third_party#76 broke the nightly build across the Triton repos; this PR chain repairs it.
Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
- Resolves: TRI-1608
CI (internal): [#58489960](http://tritonserver.local/ci/pipelines/58489960)