Repository navigation
Conversation
- describe cold-open and replay checks - preserve evidence when preflight refuses - clarify upgrade and recovery boundaries
- point both language pages to the validated source - retain the established upgrade warning text - keep the code and website guidance aligned
imbajin
left a comment
There was a problem hiding this comment.
Exact head/base and both file patches match fork Docs #47. Its original bilingual documentation was independently reviewed at 9/10; the follow-up two-link pin update was separately cross-checked at 9/10. No new documentation finding. Refusal, evidence preservation, unchanged ID format and the absence of automatic ownership repair are clear. This does not establish full original-version upgrade/replay/snapshot/per-replica rollback acceptance or replace implementation CI.
bitflicker64
left a comment
There was a problem hiding this comment.
Blocking: yes. Summary: The EN and ZH text matches the paired implementation in hugegraph/hugegraph#301 at 27731930, but that implementation is not in apache/hugegraph, so the page would document a refusal that Apache builds do not perform and cite a fork PR as its source. Evidence: apache/hugegraph master 2ae73704c has no checkLegacyGraphIdData, resolveExistingDBPath or docs/store-graphid-upgrade.md (git grep); hugegraph/hugegraph#301 is open and unmerged; latest-head CI on 6596f60 is green (prepare, Build group 0, deploy, visual).
- scope the guard to builds containing the paired fix - link the Apache implementation and upgrade guide - add matching English and Chinese section headings
Store builds with the legacy GraphID preflight refuse affected data before allocation, cold partition opening, Raft startup or staged snapshot activation. The English and Chinese HStore configuration pages explain these checks and how to preserve DB versions, metadata, WAL and snapshot evidence after refusal.
Paired implementation: hugegraph/hugegraph#301. The ID format stays unchanged; automatic ownership repair and complete deployment upgrades require separate validation. The upstream code PR will be linked when its org CI gate passes.
Validation: existing link and diff checks, one independent documentation review and the org site build passed. The paired implementation now uses effective column-family options for read-only checks; the duplicate review thread is resolved.
Org validation: hugegraph#47
Implementation overview
Documentation concept: refusal and evidence preservation, not automatic migration or runtime-upgrade proof.