feat: add import execution version to ImportMsg - #663
Conversation
Milvus selects an import's execution path (legacy V2 vs the new V3 reshard path) on the coordinator that accepts the request, behind a one-way rollout gate. Import messages can outlive that binary: pending broadcaster tasks are replayed after WAL recovery, and in CDC topologies messages are forwarded to peer clusters that may run a different binary. Without a recorded version, such consumers would re-derive the path from local state and could execute the import differently than it was accepted. Add `version` (int64, field 11) to `msgpb.ImportMsg` and regenerate the Go bindings: - 0/unspecified: legacy V2 path, so messages written by older binaries keep their behavior (backward compatible); - 2: execute with ImportTaskV2; - 3: execute with ReshardTask and ImportTaskV3. This change only defines the wire contract; version selection and enforcement are implemented on the Milvus side. Validation: - make generate-proto (protoc v3.21.4, protoc-gen-go v1.33.0) - cd go-api && go build ./... && go test ./... - git diff --check Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: xaxys <tpnnghd@163.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: xaxys The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Tick the box to add this pull request to the merge queue (same as
|
There was a problem hiding this comment.
Pull request overview
Adds an execution-version marker to msgpb.ImportMsg so import tasks can preserve the originally selected execution path (V2 vs V3) across WAL recovery and CDC forwarding, improving rolling-upgrade/heterogeneous-cluster compatibility.
Changes:
- Added
int64 version = 11toproto/msg.proto’sImportMsgwith documented semantics for0/2/3. - Regenerated Go protobuf bindings to include the new
Versionfield and accessor ingo-api/msgpb/msg.pb.go.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| proto/msg.proto | Extends the ImportMsg wire contract with a new version field and inline documentation. |
| go-api/msgpb/msg.pb.go | Updates generated Go bindings to reflect the new ImportMsg.version field. |
Files not reviewed (1)
- go-api/msgpb/msg.pb.go: Generated file
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| // tasks, WAL recovery, and CDC forwarding during rolling upgrades. | ||
| // 0: unspecified or absent; interpreted by Milvus as the legacy V2 path. | ||
| // 2: execute with ImportTaskV2. | ||
| // 3: execute with ReshardTask and ImportTaskV3. | ||
| int64 version = 11; |
issue: #662
What changed
version(int64, field 11) tomsgpb.ImportMsg;Why
Milvus selects an import's execution path (legacy V2 vs the new V3 reshard path) on the coordinator that accepts the request, behind a one-way rollout gate. Import messages can outlive that binary: pending broadcaster tasks are replayed after WAL recovery, and in CDC topologies messages are forwarded to peer clusters that may run a different binary. Without a recorded version, such consumers would re-derive the path from local state and could execute the import differently than it was accepted.
0/unset means the legacy V2 path, so messages written by older binaries remain valid (backward compatible).Behavior boundary
This PR only defines the wire contract. Version selection and enforcement are implemented in the corresponding Milvus change.
Validation
make generate-proto(protoc v3.21.4, protoc-gen-go v1.33.0 — the versions pinned by the repo and carried bymsg.pb.go, so no generator-version churn)cd go-api && go build ./...cd go-api && go test ./...git diff --check