Repository navigation
Conversation
- compile core tools with Java 17 and current mocking support - install and verify the locked same-source SDK in isolated CI repositories - separate released server JVMs and candidate fixture configuration - document migration boundaries and cover runtime license changes
- include the latest reviewed Spark preparation ancestor - keep the released fixture JVM scoped by the shared action - preserve the reviewed Java 17 candidate workflow
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3170e0d3f1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Give each HTTPS test its own client and clean it up only when opened. - Clear the client even when closing fails so teardown cannot reuse it. - Prepare the pinned official trust store once per class and verify downloads. - Compile and probe negative builder lifecycle on JDK 11 and 17 without server writes.
- inherit the current public module prerequisite commits - preserve Java 17 compilation and candidate charset behavior - keep isolated HTTPS fixtures and safe H2 validation errors - include Spark TLS configuration and credential-safe logging
- qualify the published Common request encoding limitation - keep candidate deployment requirements tied to actual behavior - retain UTF-8 options for the earlier preparation build
- link Cucumber bundled MIT and Boost grants explicitly - retain embedded copyrights and existing full license texts - document the companion Java 17 image build prerequisite
- include the current reviewed Spark preparation head - preserve candidate production and dependency settings - keep the union as a review prerequisite branch
- keep generated JKS files outside text formatting checks - retain the exact pinned certificate fixture bytes - preserve normal source style and build verification
- retain exact notices for current runtime dependencies - include shared license files in Loader and Tools archives - omit macOS sidecars from the combined distribution
- record original and candidate server validation boundaries - retain the original Client 1.5 Gremlin alias limitation - distinguish backend checks from pending Hubble browser gates
- retain the current candidate SDK and Java 17 build settings - inherit validated Spark endpoint and H2 memory guards - preserve the reviewed package legal and archive changes
- retain all module prerequisites as ancestors - carry verified launcher process guards into the candidate - inherit isolated cross-platform launcher regression checks
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 93600349b4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 93600349b4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| The Java 17 server candidate retains the Maven version `1.7.0`. Its Common, PD, | ||
| gRPC and Store artifacts must come from the same source commit; Maven Central | ||
| artifacts with that version are not interchangeable with the candidate. |
There was a problem hiding this comment.
For downstream Maven consumers, the isolated candidate repository created by the build scripts is unavailable: the flattened Toolchain POMs still declare org.apache.hugegraph dependencies at 1.7.0, so Maven resolves the published Central artifacts that this section explicitly says are not interchangeable with the candidate. A Toolchain 1.8 artifact can therefore run against different Common/PD/gRPC code than it was compiled and tested with, causing linkage or behavioral failures; give the candidate artifacts deployable, distinct coordinates and reference those coordinates before publishing the Toolchain artifacts.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Agreed that external Maven consumers need distinguishable published SDK identities. The migration guide now makes this an explicit release gate: before a release candidate or public Maven deployment, every Java 17 SDK coordinate must differ from the released 1.7.0 artifacts, be available to consumers, and be used for a fresh dependency/runtime matrix validation. This work keeps the locked source for isolated candidate validation; SDK versioning and publication remain separate release work.
- preserve raw SDK provenance in CI and refreshed archives - test Tools against candidate and released 1.7 fixtures - clear source-field errors with native form updates - wait for retry-button readiness in frontend tests - document SDK coordinates required before Maven publication
bitflicker64
left a comment
bitflicker64
left a comment
There was a problem hiding this comment.
Blocking: yes. Score: 6/10. Summary: The Java 17 switch (release 17 in the parent, module overrides removed), the candidate/release-1.7 CI matrix and the fixture repository isolation look correct, and CI is green. Two documents assume the candidate SDK, but the documented default build still resolves the Maven Central 1.7.0 SDK under the same coordinates, which changes Spark request encoding and the jars bundled in Hubble. Evidence: read the diff against java17-module-prerequisites (license text skimmed); compared AbstractRestClient.buildRequestBody at apache/hugegraph 1.7.0 and the locked candidate commit 4c162f5; ran a JDK 17.0.20 charset probe with LANG=C; ran node --test install-server.test.cjs (19 pass), test_configure_gremlin_fixture.py (3 pass) and bash -n on the changed scripts.
- clarify the default Maven SDK source - retain driver and executor UTF-8 options - qualify the isolated candidate SDK exception
- replace dated results with compatibility scope - remove separate PR rollout instructions - retain SDK identity and release validation requirements
- retain Hubble request and launcher ownership - inherit loader diagnostics and regression coverage - align current SDK guidance and notice mappings
- inherit finalized prerequisite branch content - preserve component-specific Java 17 changes - reconcile upstream squash history without rewriting heads
- inherit the upstream-ready metadata guide - remove the historical validation screenshot - preserve module-specific code and configuration # Conflicts: # hugegraph-hubble/README.md
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
1 similar comment
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Reject distribution audits when the JDK jar tool is missing. Stop the audit when a bundled JAR cannot be enumerated. Read complete JAR listings before detecting native entries. Cover failure and success paths with CI regression tests.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
本轮 Linux 分布式验收仍在进行中。真实 Chrome、完整认证矩阵和导入复测尚未完成，当前不能据此判断发行就绪。 锁定组合已完成隔离同源构建、实际 JDK 17 运行核验，以及候选 SDK 来源和 bundled JAR 校验。A 匿名单元实际为单 PD/Store/Server；B 匿名单元实际为三 PD/Store/Server，数据分区核实为三个 voting peers。两套均使用真实 HStore，Hubble 没有填写手工 Server URL，能够经 PD 发现服务；这些运行/API 证据不替代浏览器验收。 A 已完成独立节点故障和整套干净重启，保留的 schema、点属性及 API 准备的 Hubble 收藏元数据一致。B 已完成真实 PD leader、数据 Store leader、Server 单节点故障、Store 多数派丧失与恢复，以及整套干净重启，保留数据和 schema 一致。失去两个 Store 时实际数据请求超时或拒绝；恢复后逐条核对确认写入和超时请求。部分超时写入最终落盘，按不确定请求记录。缓存读取、Hubble 图列表和陈旧的 PD 健康元数据可能仍成功，不能用来宣称存储就绪。这里仅验证单机进程级行为。 已正常推送两项局部修复，均经过适用回归、完整包核验及三名独立只读复审。
完整原始 Client API、Func、Loader file 和 Tools Func 套件已在 A 认证 HStore 上执行，保留全部断言，结果均未通过。部分失败来自旧容量上限、RocksDB backend 和全局 auth 夹具前提；现代 GraphSpace 的跨空间关系拒绝不能被关闭以迎合旧测试。Func 的 metrics 断言还假设实例只有一个图，与本次保留的验收图不同；此项不能误判为 metrics 丢数据。OLAP 的 ALL 读取缺字段已在新 HStore 图缩成一点复现：schema 任务成功、三次写入返回该点 ID，读取模式确认 ALL 后，按 ID 和列表读取仍缺 OLAP 属性。Project 的非空 graphs 解码失败已独立复现（见新增 P1）；异步 schema/ID reset 异常及时间字段问题仍在做最小复现，不混同为已确认的统一根因。认证 Server 的无凭据/错误凭据拒绝和管理员独立 CRUD 已核验，Chrome 登录与权限矩阵仍未执行。 Tools 的 auth restore 因现代 GraphSpace 关系约束失败，两种 backup/restore 在 schema 准备阶段已失败，不能说数据恢复阶段已完成；原测试还手动恢复模式，不能作为自动收尾证明。 TODO
运行验收使用锁定包；修复包有独立来源、归档和运行记录，复测后恢复锁定构建。临时 TLS fixture 已正常停止，A 认证单元原 Hubble 已恢复，原 A 匿名单元保留数据停机，B 匿名单元已停机保留数据，当前 B 认证单元运行。checksum/signature sidecars 未检查，不声称完整发行签名验收。后续只更新本条审计评论，不重复发布。 认证空间与整套重启补充
B 认证三副本阶段
认证 Store 数据 leader 与 Project 补充
独立 Server API 故障与容量边界
|
- retry only typed connection failures among PD candidates - preserve authentication and TLS failures during health checks - close unsuccessful clients and reject exhausted candidates - cover unavailable servers and handshake error boundaries
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
- inherit the actual ASF Hubble squash commit - preserve published SDK and Hubble review fixes - keep candidate runtime and source contracts intact
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
1 similar comment
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
- identify pre-merge organization repository and commit pins - require coordinated migration to ASF after the Server merge - document the preferred transition to published SDK identities
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
- retain reusable module workflows and shared fixtures - reconcile candidate SDK validation with the Java 17 baseline - preserve reviewed module behavior and source contracts # Conflicts: # .github/actions/setup-hugegraph-server/action.yml # .github/workflows/client-ci.yml # .github/workflows/codeql-analysis.yml # .github/workflows/hubble-ci.yml # .github/workflows/license-checker.yml # .github/workflows/loader-ci.yml # .github/workflows/server-fixture-ci.yml # .github/workflows/spark-connector-ci.yml # .github/workflows/tools-ci.yml # hugegraph-hubble/hubble-dist/assembly/travis/download-hugegraph.sh # hugegraph-hubble/hubble-dist/assembly/travis/hugegraph-server1/install-hugegraph.sh # hugegraph-hubble/hubble-dist/assembly/travis/hugegraph-server2/install-hugegraph.sh
- align the prerequisite review base with current ASF master - retain candidate migration behavior unchanged - keep dependent organization review diffs focused
- describe the recorded release and candidate identities - distinguish Go service inputs from planning metadata - retain recovery guidance for failed baseline resolution
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
1 similar comment
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
- use Java 17 for Loader image builds and runtime - install Python and Git required by SDK packaging - bootstrap and verify the locked SDK inside image builds - include the SDK verifier in Docker build contexts
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Validate GitHub stack topology and canonical base trees. Record stack identity and recheck current branch inputs. Reject malformed metadata and cover stale merge cases.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
After the module prerequisites, Client, ordinary Loader, Tools and Hubble now require Java 17 and use a locked, same-source candidate SDK in an isolated Maven repository. Released Server 1.7 retains its supported JVM and independent dependency fixture.
- preserve the exact ASF core squash tree - link the finalized candidate cutover source - avoid repeated conflicts in dependent PRs
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This switches the Java Client, ordinary Loader, Tools and Hubble to Java 17 after module preparation in #40–#45. Before this change, the shared build used older bytecode and published HugeGraph dependencies. The candidate build now installs the locked server reactor into an isolated Maven repository so Common, Core, PD and Store artifacts come from the same source. Released Server 1.7 retains its supported Java 11 JVM and separate dependencies.
TODO (apache/hugegraph#3263): the organization Server source is only a pre-merge validation input. After the Java 17 Server migration merges, switch to verified ASF source and revalidate SDK/runtime compatibility; prefer distinct staged SDK coordinates when available. Do not retain the temporary fork/ref/SHA after the merge.
The base materializes sibling prerequisites for review. Merge #40 first, then #41/#42/#43/#45 independently; #44 follows #41 and #45 so overlapping release metadata is coordinated before Hubble. After those prerequisites land, retarget this PR to master. The prerequisite union is not an additional merge unit. Container builds follow in #37; Spark Loader and Flink CDC are separate stacks in #38 and #47.
flowchart LR source[Locked server source] --> sdk[Isolated same-source SDK] sdk --> tools[Core tools on Java 17] tools --> checks[Runtime compatibility checks] legacy[Released servers on supported JVMs] --> checks candidate[Candidate server on Java 17] --> checksThe migration guide records separate installation, Loader usage, ZIP/plain backup migration, Hubble H2 metadata handling and the measured compatibility matrix. Previous distributions, metadata and graph data are retained. Standalone Loader and Tools archives include the shared legal files; combined archives omit macOS sidecars. The original candidate SDK manifest is retained by CI and copied into each candidate distribution, with stale staging metadata removed before the optional copy. Distinct, publicly available SDK coordinates and renewed compatibility checks are required before any external Maven publication or release candidate.
Tools CI defines separate candidate and released Server 1.7 fixtures. Hubble field selection now clears the previous native form-validation error when selecting fields or changing data sources; the regression checks that validation state directly. The retry-button test waits until the control is usable before clicking, while preserving its original retry assertions.
Validation includes a clean native Java 17 reactor build, subsequent Hubble backend and script packaging checks, Client/Loader/Hubble tests, Client API/functional and ordinary Loader/Tools flows against released Server 1.7 and the locked candidate, packaged Loader/Tools on standalone Server 1.5, original Client compatibility probes, and old Tools backup restoration. Original Client 1.5 REST cases pass against the candidate; its legacy Gremlin alias remains an observed limitation.
The source increments passed three independent reviews. Full frontend tests, lint, translations and the new optimized build pass. All four distributions were assembled through their configured Maven goals and independently checked: the new UI and exact raw SDK manifest are present, while every Java JAR, SDK artifact, launcher and legal payload preserves its verified bytes. Hubble process-identity tests passed in actual Ubuntu and macOS CI. Core CI covers Tools functional tests against candidate and released Server 1.7 fixtures and uploads independent SDK manifests. Required checks must pass on the current head before merging. The image/API-engine and Flink recovery checks passed on their respective earlier source trees; their final rebased stacks still require fresh CI.
Final Hubble candidate-SDK browser workflows, browser-created metadata persistence and complete HBase bulkload/backend readback remain pending. Unit tests, form-state checks and HFile generation do not establish those flows. PR merge and formal release are outside this delivery.
The consolidated upstream CI is retained: module workflows remain reusable, and shared composite actions configure Java, Maven repositories and service startup. Central precedes ASF Stage without a per-workflow boolean switch; CI requires Maven 3.9 or newer.
Latest CI integration validation: workflow lint, CI policy, shared fixture and initialization contracts, SDK verifier, installer and Hubble helper regressions pass locally. Updated-head remote integration checks remain pending. The historical Server 1.7 fixture still uses the inherited build-once source package; Docker replacement and removing source SDK bootstrap after staged SDK availability remain follow-up work.
CI fixes include the Java 17 Docker build foundations required by the core cutover (SDK bootstrap, Python verification and build-context inclusion), plus exact canonical-base validation for GitHub native PR stacks. Image startup gates and ordinary PR freshness checks remain enforced. The image-specific CI/cache/provenance extensions remain in the separate image PR. Local policy and image-context regressions pass; full new-head image builds and runtime tests remain pending CI.