FrankChen021 commented on PR #20014: URL: https://github.com/apache/druid/pull/20014#issuecomment-5299785601
## Codex dependency triage: CLOSED_HIGH_EFFORT / WONT_FIX_LARGE_CHANGE Verified immediately before this comment: PR is OPEN, unmerged, mergeable=true, exact head `ec50b7eb770eedcfb75a2235f63e9e8c2806a0b9`; latest fetched `origin/master` is `04d643f5fb6afb81032d17e0b7b85393883fbde3`. The exact three-dot diff is one line in `extensions-core/kubernetes-overlord-extensions/pom.xml`: `vertx.version` 4.5.28 -> 5.1.6. Findings: * The effective graph keeps Fabric8 `kubernetes-httpclient-vertx:7.8.0`, whose compiled client was built against Vert.x 4.5.28, while the direct Druid dependencies force Vert.x Core/Web Client 5.1.6. The Fabric8 builder invokes the removed Vert.x 4 API `WebClientOptions.setMaxPoolSize(int)`, so the application would fail with `NoSuchMethodError` on the Kubernetes client construction path. * Druid itself imports the removed `io.vertx.core.spi.resolver.ResolverProvider`; the PR CI compile failures all report this missing package/symbol. A local JDK 25 compile confirmed it. A temporary source-only property-key shim made main compile, but focused test compilation then failed because existing tests call the removed `WebClientOptions.getMaxPoolSize()` API. * Vert.x 5 moves HTTP pool configuration from `HttpClientOptions` to `PoolOptions`. Fabric8 7.8.0 provides a separate `kubernetes-httpclient-vertx-5` / `Vertx5HttpClientFactory` implementation, with a different package and `additionalConfig(WebClientOptions, WebSocketClientOptions, PoolOptions)` contract; Fabric8 documents the Vert.x 4 and 5 modules as mutually exclusive. This is not a safe one-property update. * A supported migration would require coordinated POM artifact/exclusion changes, Druid factory inheritance and callback changes, preservation/redesign of `webClientOptions` pool configuration, test updates, documentation updates, license manifest/version updates, and Kubernetes HTTP/WebSocket/TLS/runtime validation. A partial source shim would leave a binary runtime failure and changed user-visible pool behavior. * The change does not alter Druid stored-data or serialization formats, but it does alter the Kubernetes client runtime and connection-pool/WebSocket behavior. The current `licenses.yaml` entry still records Vert.x 4.5.28; accepting Vert.x 5 would require a maintained license/version review. Vert.x 5 release/migration material also documents major API changes and security fixes in the 5.x line; those benefits do not make this unvalidated client migration safe. Checks: all 28 current runs are terminal. The 22 failures are all PR-caused cascades from the same Vert.x compile break (13 JDK25 unit shards, 4 QTest shards, `validate-dist`, 5 Static Checks jobs, and 3 CodeQL component jobs). `actions-timeline`, title validation, and label triage pass; CodeQL rollup is neutral because its components failed; coverage and Docker jobs are skipped. No failure was classified as infrastructure, permission, or flake, so no jobs were rerun. No rebase, code commit, branch push, or approval was performed. The temporary compatibility experiment was reverted; the isolated worktree is clean. Closing because the required compatibility work is a coordinated, behavior-sensitive migration rather than a surgical dependency bump. This PR should not be merged as submitted. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
