mirror of
https://github.com/milvus-io/milvus.git
synced 2026-07-21 10:15:43 +00:00
master
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Li LiuandGitHub
|
c819a2c5e1 |
build(deps): upgrade go toolchain to 1.26.5 (#51271)
## What - Upgrade the root, pkg, client, test, and telemetry example modules from Go 1.26.4 to Go 1.26.5. - Upgrade CPU/GPU builder Dockerfiles, macOS CI Go setup, KRTE build arg, rpm setup, meta-migration builder, and go-client test image to Go 1.26.5. - Point CPU and GPU builder consumption in `.env` to the successful build-env tag `20260714-c135601`. ## Why - Latest direct Trivy scan of `milvusdb/milvus:master-20260711-1993feae-amd64` reports CVE-2026-39822 in Go stdlib 1.26.4, fixed in 1.26.5. - The normal daily image scan is currently blocked through Jenkins `milvus_scan_image_daily` #540 with `exec format error`; last successful scan is #508 from 2026-06-10, so this was verified by direct image scan. ## Image coverage - Go toolchain fixes are shared by all Milvus runtime images; no per-OS runtime Dockerfile package change is required. - Builder definitions are updated for CPU ubuntu22.04, ubuntu20.04, ubuntu24.04, amazonlinux2023, rockylinux9 and GPU ubuntu22.04, ubuntu20.04. - No runtime image variant is deliberately skipped; this is not an OS-package CVE. ## Verification - `go.dev/dl/?mode=json&include=all` confirms go1.26.5 is stable and linux amd64/arm64 tarballs exist. - `go env GOTOOLCHAIN GOVERSION` selects `auto` / `go1.26.5` after the module update. - `go list -m` succeeds for root, pkg, client, tests/go_client, and both telemetry examples. - `cd pkg && go test -tags dynamic,test -gcflags="all=-N -l" -count=1 ./util/typeutil` passes after rebasing onto the latest upstream master. - Jenkins build-env #40 succeeded and published builder tag `20260714-c135601`; `.env` now selects that tag for CPU and GPU CI builds. - A repo-wide audit found no remaining Go 1.26.4 toolchain pins. Note: full root `go mod tidy` is not included because this checkout has a root-owned `deployments/docker/dev/volumes/etcd/member` directory that makes `go mod tidy` fail with permission errors; `go mod tidy -e` subsequently OOMed locally. No go.sum changes were produced by the successful module tidies. Generated by autonomous CVE maintenance. --------- Signed-off-by: Li Liu <li.liu@zilliz.com> |
||
|
|
e2787d3981 |
enhance: standardize error handling on merr + Sys/Input classification (#50221)
issue: #47420 ## What this PR does Project-wide migration of raw `fmt.Errorf` / `errors.New` in function bodies onto the `merr` framework, plus the Sys-vs-Input error classification and the machinery it drives (retriability, fine-grained metrics, segcore unification), plus the convention docs and a linter that keeps it from regressing. Scope: storage, proxy, coordinators (root/data/query), query node, data node, `pkg/util` & `internal/util`, expression parser, message queue, streaming, and misc packages. Bare raw-error usages went from ~3000 to a ~340 allowlist (package-level sentinels / build-tag / test sites). --- ## How to review this PR It is large but the vast majority is mechanical. Changes fall into three tiers; spend review budget on Part 2 and Part 3. ### Part 1 — Mechanical standardization (low risk, verify by rule) Each converted call follows one of a small fixed set of rules. To review, check that each site obeys the matching rule rather than reading every line: | Pattern | Rule | |---|---| | `fmt.Errorf("...")` originating a new error | → `merr.WrapErrXxxMsg("...")` with a code matching the failure's meaning | | Adding context to an existing typed error | → `merr.Wrap(err, "...")` / `merr.Wrapf(...)` — **preserves** the inner code (never `WrapErr*Err`, which overwrites it) | | Errors inside the streaming subsystem | → `status.New*` factories (StreamingError), **not** merr — this is the component-internal dialect (see `docs/dev/error_handling_guide.md`) | | Low-level / control-flow signal caught by `errors.Is` | → kept as a package-level `errors.New` sentinel (lowercase, same-package) | Conventions are documented in `docs/dev/error_handling_guide.md` (how-to) and `docs/dev/error_sentinel_convention.md` (rules + audit). A `gocritic`/`ruleguard` rule (`rawmerrerror`, in `rules.go`) enforces "no raw `return errors.New/fmt.Errorf`" under `make verifiers`. ### Part 2 — Behavior changes (review these closely) These are the sites where the wire contract or runtime behavior changes, not just the source text. Listed by category; representative locations given, full set in the diff. **A. gRPC wire-code shifts: `UnexpectedError(1)/Code 65535` → typed code.** Where a handler previously returned a raw error (collapsed to `Code=65535` on the wire), it now returns a typed merr, so the client sees a real code. The most common shift is to `IllegalArgument(5)/Code 1100` (ParameterInvalid). Touch points include datanode task handlers (CreateTask/Query/Drop), proxy Upsert, querynode GetMetrics, datacoord CreateIndex, httpserver query-response builder, and typeutil schema validation. One code refinement: an index-param validation moved `1100` → `1101` (ParameterMissing). **Client/SDK assertions and any code that switched on `Code=65535` for these paths must be re-checked** (the go_client e2e assertions were already aligned in this PR). **B. Prometheus `status` label contract change (externally visible).** The proxy metric's coarse `fail` / `rejected` values are split into `fail_input` / `fail_system` and `rejected_user` / `rejected_system` (in `requestutil.ParseMetricLabel`; auth/privilege rejections count as `rejected_user`), so dashboards can attribute a failure to caller vs operator. **Dashboards/alerts querying `status="fail"` must migrate to `status=~"fail_.*"`, and `status="rejected"` to `status=~"rejected_.*"`.** The in-repo Grafana dashboard is already migrated; external dashboards built on the old values silently go empty after upgrade. This is the one change that requires an ops-side migration. **C. Retriability semantics.** - C1: `merr.Status(err)` now forces `Retriable=false` when the error is an `InputError` — a malformed request can never succeed on blind retry, so clients never get the self-contradictory "your input is wrong but you may retry". - C2: `retry.Do` short-circuits an `InputError` (non-retriable) — **but only when the caller did not pass a `RetryErr` predicate**. The check is an `if c.isRetryErr != nil { ... } else if InputError { ... }` *mutually exclusive* branch (`pkg/util/retry/retry.go`): an explicit `RetryErr` takes precedence and bypasses the InputError abort. `retry.Handle` deliberately does **not** apply the InputError abort (its callers signal abort via `shouldRetry=false`). Four flusher startup callsites that must retry through transient "not ready" errors were given explicit `RetryErr` escape hatches. **D. segcore (C++→Go) error classification.** A single shared Go-side table (`pkg/util/merr/segcore.go`) maps each segcore code to a merr sentinel + InputError/signal category, replacing scattered hand-written `if errorCode == ...` switches in the cgo wrappers. **Wire `Code` values change for every segcore pass-through error, not just the remapped ones.** Named sentinels remap (C++ `2003` → merr `2001`, `2033` → `2002`, Folly/Knowhere codes likewise); **all remaining pass-through codes (`2004`–`2043`, previously surfaced to clients as raw C++ enum values) now serialize as `2000`** (`ErrSegcore`), with the original C++ code preserved in the `Reason` text (`segcoreCode=...`); unknown/future codes collapse to `2000` as well (pinned by the `wire_code_projection` test). Transient segcore classes (object storage / file IO / OOM / mmap / FieldNotLoaded — 11 codes) now report `Retriable=true`. **Any client switching on raw segcore codes in the `2004`–`2043` range must be re-checked**; the in-Reason code remains available for diagnostics. Signal codes (PretendFinished / FollyCancel) are recognized centrally. `errors.Is`-based control flow on these (e.g. scheduler skip/retry) is preserved. **E. InputError classification (25 sentinels + dynamic marks).** 25 sentinels in `errors.go` carry `WithErrorType(InputError)` (the Collection / ResourceGroup / Database families, `ErrIndexDuplicate`, `ErrParameterInvalid`, `ErrPrivilegeNotAuthenticated`, `ErrImportFailed`, `ErrQueryPlan`, ...), plus dynamic marks for the 8 segcore input codes (ExprInvalid, DimNotMatch, MetricTypeInvalid, FieldIDInvalid, ...) and `WrapErrAsInputError`. The widest blast radius is `ErrParameterInvalid` (1100): ~2335 `WrapErrParameterInvalid*` callsites now classify as input / non-retriable. Because of C1/C2 this changes retriability for any path that returns these. **The audit to confirm no transient path was mis-marked is the single most important review item** (see Part 3). One reverse correction: storage field-stats parsing moved from `ErrParameterInvalid` (input) to `ErrDataIntegrity` — a corrupted stored stat is data corruption, not user input. ### Part 3 — Known risks & traps (called out proactively) 1. **`merr.Wrap` vs `WrapErr*Err` (code-masking).** `WrapErr*Err` builds a `wrappedMilvusError{sentinel: ErrServiceInternal}` whose `code()` returns the *outer* sentinel — it overwrites the inner typed code and hides the `errors.Is` chain. This is intentional (use it to *deliberately* downgrade), but it was a recurring conversion defect; the rule "add context with `merr.Wrap`, downgrade with `WrapErr*Err`" is enforced by convention and reviewed across the diff. 2. **InputError × `retry.Do` blast radius.** Marking a sentinel `InputError` makes any `retry.Do(...)` without a `RetryErr` predicate stop retrying it. Reviewers should sanity-check that no transient use of the 19 newly-marked sentinels (especially `ErrParameterInvalid`) sits inside a retry loop that needed to keep spinning. The known flusher cases were handled (see C2). 3. **The ~340 raw-error allowlist.** What remains as bare `errors.New` is, by design: package-level sentinels (caught by `errors.Is`), `//go:build test` sites, and out-of-band trees (`cmd/`, `tests/`, codegen, walimpls). The linter only bans the *direct-return* form; assignment-then-return escapes and the full no-exceptions ban are deferred to an AST-based linter (Tier 2, documented). 4. **segcore C++ second step deferred.** This PR unifies classification on the Go side; splitting the dual-semantic C++ codes at the source is a follow-up. --- ## Validation - `make verifiers`: Go side clean (gofmt + static-check across modules, including the new `rawmerrerror` rule with a 0-hit baseline repo-wide). - `make test-go`: passing; the one real regression introduced (a datanode `invalid_task_type` assertion shifting `1` → `5` from a ParameterInvalid conversion) was fixed in-tree. - go_client e2e CreateIndex assertions aligned to the new merr messages. --------- Signed-off-by: zhenshan.cao <zhenshan.cao@zilliz.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
986dcb42e6 |
build(deps): upgrade go toolchain to 1.26.4 (#48803)
## Summary - Bump **Go to 1.26.4** across CI workflows, Docker builders, RPM setup, and the `go` directive in all 4 modules (+ examples). - Refresh Go 1.26-compatible deps to latest: `sonic` v1.15.2, `mockey` v1.4.6, `gopkg` v0.1.4, `sonic/loader` v0.5.1, `cpuid/v2` v2.3.0. sonic 1.14.x fails to build on the 1.26 compiler (bytedance/sonic#895). - **datacoord tests:** replace the anonymous `struct{ Iface }` mockey idiom with **named helper types** (`embeddedHandler`/`embeddedBroadcastAPI`/`embeddedBroker`/`embeddedAllocator`). ## Why the datacoord test change Go 1.26's `printf` vet pass (run automatically by `go test`) calls `x/tools/refactor/satisfy.Finder` unconditionally and **panics `(*ast.StructType)`** on a **method expression of `*struct{ Iface }`** — an upstream Go toolchain bug. Only `internal/datacoord` used this mockey idiom (31 sites in 2 test files; verified repo-wide it's the only place), which is why only `build-ut-cov`/`ut-go` failed on `internal/datacoord [build failed]`. Switching to a **named type** makes the method-expression receiver an identifier instead of a struct literal, so `satisfy.Finder` no longer panics. mockey usage and test behavior are unchanged. Minimal repro: `type I interface{ Logf(string, ...any) }` + `var _ = (*struct{ I }).Logf` under `go 1.26` → `go vet` panics; named type does not. ## Notes - `.env` builder-image tag intentionally not hand-edited (auto-bumped post-merge by `bump-builder-version`). - The bug also warrants an upstream report to golang/go (reproducer above). ## Test plan - [x] `go mod tidy` clean across all four modules - [x] sonic 1.15.2 + mockey compile on go 1.26.4 - [x] reproduced the vet panic; verified named-type method expression avoids it; gofmt-clean - [ ] Full CI (build / build-ut-cov / ut-go / ut-cpp / integration) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: xiaofanluan <xiaofan.luan@zilliz.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
congqixiaandGitHub
|
7311d450a0 |
enhance: bump Go dependencies to v3 modules (#49485)
Related to #49398 Bump Go module references from pkg/v2 and milvus-proto/go-api/v2 to pkg/v3 and milvus-proto/go-api/v3 so the client tracks the Milvus 3.x release line. This prepares the repository for the upcoming 3.x.y release by aligning imports, module dependencies, and proto API references with the new major-version module paths. --------- Signed-off-by: Congqi Xia <congqi.xia@zilliz.com> |
||
|
|
b0ec4a2dd8 |
fix: upgrade Go to 1.25.8 for CVE-2025-68121, CVE-2026-27142, CVE-2026-25679 (#48286)
issue: #48574 ## Summary - Upgrade Go from 1.24.12 to 1.25.8 across all go.mod files and Dockerfiles - Fixes CVE-2025-68121 (CRITICAL), CVE-2026-27142 (HIGH), CVE-2026-25679 (HIGH) in Go stdlib - All three CVEs affect the Go standard library and are resolved by upgrading to Go 1.25.8 ## Changes - Updated `go` directive in go.mod files (root, pkg/, client/, tests/go_client/, examples/) - Updated Go download URLs in Dockerfiles (build/docker/builder/) - Updated `toolchain` directives where present issue: https://github.com/milvus-io/milvus/issues/TBD ## Test plan - [x] `make milvus` builds successfully with Go 1.25.8 - [ ] CI passes 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Li Liu <li.liu@zilliz.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|
tinswzyandGitHub
|
aed7c8bcfb |
enhance: update WP version v0.1.25 (#45011)
#43638 update wp to latest Introduce the beta version of the wp service mode. --------- Signed-off-by: tinswzy <zhenyuan.wei@zilliz.com> |
||
|
XiaofanandGitHub
|
8b6a3a0aa4 |
feat: Add client-side telemetry with heartbeat and server command support (#47523)
issue: #47281 design doc: https://github.com/milvus-io/milvus-design-docs/blob/main/design_docs/20260131-client_side_telemetry.md Implement comprehensive client-side telemetry system that includes: - Metrics collection for Search, Query, Insert, Delete, Upsert operations - Automatic heartbeat reporting to server with configurable intervals - Per-collection metrics tracking with wildcard support - P99 latency calculation using ring buffer sampling - Server-push command handling (push_config, collection_metrics, show_errors) - Historical snapshot storage for latency history queries - Error tracking with circular buffer for recent errors - WebUI for telemetry visualization and command management - HTTP API endpoints for telemetry data access and command push - RootCoord telemetry manager for centralized command routing Signed-off-by: xiaofanluan <xiaofan.luan@zilliz.com> |