Repository navigation
Conversation
….2-jre Upgrades gRPC to 1.85.1 (bundling Netty 4.2.17.Final for CVE-2026-75595), OpenTelemetry to 1.67.0 (for CVE-2026-45292 and CVE-2026-118259), and Guava to 33.7.2-jre (for CVE-2026-102554) across shared dependencies and parent POMs.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates several dependency versions across multiple Maven POM files, configuration files, and dependency declarations. Specifically, it upgrades Guava to 33.7.2-jre, gRPC to 1.85.1, and OpenTelemetry to 1.67.0 to maintain consistency across modules. I have no feedback to provide.
…bator to 1.67.0-alpha Bumps conscrypt-openjdk-uber to 2.8.0 so Airlock resolves the trusted version over grpc-alts 1.85.1's transitive 2.6.1, and aligns spanner-jdbc's test-scoped opentelemetry-api-incubator with opentelemetry 1.67.0.
| <awaitility.version>4.3.0</awaitility.version> | ||
| <slf4j.version>2.0.16</slf4j.version> | ||
| <conscrypt.version>2.6.2</conscrypt.version> | ||
| <conscrypt.version>2.8.0</conscrypt.version> |
There was a problem hiding this comment.
qq, is conscrypt bump to resolve some deps/ CI issue? I don't think I saw a CVE report for this
| packaging: jar | ||
| - name: protoc-gen-java_grpc | ||
| version: 1.83.0 | ||
| version: 1.85.1 |
There was a problem hiding this comment.
Is there any generated code change due to this grpc upgrade? If yes, can we include them in the same PR? Here is the latest generation guide via Librarian.
There was a problem hiding this comment.
Verified by running librarian install && librarian generate with protoc-gen-java_grpc: 1.85.1 — it produces zero diff across generated *Grpc.java files (comparing grpc/grpc-java v1.83.0...v1.85.1 also confirms no template changes in java_generator.cpp). Also pushed a commit updating GapicSpannerRpcTest to register a SpanProcessor for OpenTelemetry 1.67.0.
No concerns since they are for CVEs. The Spanner test failures seem to be legit, we may need code changes in Spanner. |
The failures seem related to a change discussed in OpenTelemetry #8740 that affects SdkTracerProviders without a SpanProcessor. It seems reasonable to switch the failing tests to include a SpanProcessor (e.g. precedent in OpenTelemetrySpanTest), but it seems like we should be cautious here since this is a behavioral change. |
…ntext tests OpenTelemetry 1.67.0 returns a noop tracer when no SpanProcessor is registered on SdkTracerProvider. Attach an InMemorySpanExporter processor so trace context propagation headers are emitted.
|
Updated spanner test, maybe someone from spanner team can take a look? |
…OpenTelemetry.getTracer
mutianf
added
the
kokoro:force-run
yoshi-kokoro
removed
the
kokoro:force-run
| this.openTelemetry = openTelemetry; | ||
| Package pkg = this.getClass().getPackage(); | ||
| if (pkg != null) { | ||
| if (pkg != null && pkg.getImplementationVersion() != null) { |
There was a problem hiding this comment.
Is this change required by a behavioral change from the opentelemetry upgrade?
Upgrades gRPC to
1.85.1(bundling Netty4.2.17.Finalto address CVE-2026-75595), OpenTelemetry to1.67.0(for CVE-2026-45292 and CVE-2026-118259), and Guava to33.7.2-jre(for CVE-2026-102554) across shared dependencies and parent POMs.