mirror of
https://gitee.com/milvus-io/milvus.git
synced 2025-12-28 14:35:27 +08:00
bf5fde1431
issue: #42098 #42404 Fix critical issue where concurrent balance segment and balance channel operations cause delegator view inconsistency. When shard leader switches between load and release phases of segment balance, it results in loading segments on old delegator but releasing on new delegator, making the new delegator unserviceable. The root cause is that balance segment modifies delegator views, and if these modifications happen on different delegators due to leader change, it corrupts the delegator state and affects query availability. Changes include: - Add shardLeaderID field to SegmentTask to track delegator for load - Record shard leader ID during segment loading in move operations - Skip release if shard leader changed from the one used for loading - Add comprehensive unit tests for leader change scenarios This ensures balance segment operations are atomic on single delegator, preventing view corruption and maintaining delegator serviceability. --------- Signed-off-by: Wei Liu <wei.liu@zilliz.com>
Integration test
This folder contains the integration test for Milvus components.
How to run integration test locally
Integration test still need some thirdparty components to start:
cd [milvus-folder]/deployments/docker/dev && docker compose up -d
Run following script to start the full integration test:
cd [milvus-folder]
make milvus # milvus needs to be compiled to make cpp build ready
./scripts/run_intergration_test.sh
If you want to run single test case, you could execute command like this example
# mq, etcd, minio ready before
cd [milvus-folder]
source scripts/setenv.sh
cd tests/integration/[testcase-folder]/
go test -run "$testCaseName^" -testify.m "$subTestifyCaseName^" -race -v
Recommended coding style for add new cases
Using suite
MiniClusterandMiniClusterSuite` provides lots of comment preset tool function to execute intergration test.
It is recommend to add a new test with testify/suite
import (
// ...
"github.com/milvus-io/milvus/tests/integration"
)
type NewSuite struct {
integration.MiniClusterSuite
}
// Setups and teardowns, optional if no custom logic needed
// example to suite setup & teardown, same logic applies to test setup&teardown
func (s *NewSuite) SetupSuite() {
s.MiniClusterSuite.SetupSuite()
// customized setup
}
func (s *NewSuite) TearDownSuite() {
s.MiniClusterSuite.TearDownSuite()
// customized teardown
}
New folder for each new scenario
It's a known issue that integration test cases run in same process might affect due to some singleton component not fully cleaned.
As a temp solution, test cases are separated into different packages to run independently.