congqixia 6f94d8c41a
fix: Handle legacy binlog format (v1) in segment load diff computation (#46598)
When computing load diff, binlogs in v1/legacy format have empty
child_fields. In this case, the field_id itself should be used as the
child_id (group_id == field_id for legacy format).

Without this fix, legacy format binlogs are not recognized during diff
computation, causing segments to fail loading and TestProxy to timeout.

Changes:
- Add fallback to use fieldid as child_id when child_fields is empty
- Add LoadDiff::ToString() for debugging
- Add logging for diff in Load/Reopen operations
- Add comprehensive unit tests for legacy format handling

Related to #46594

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
- Core invariant: load-diff computation must enumerate every binlog
child group for a field so current vs new segment state comparisons
include all column-group/binlog groups; for legacy (v1) binlogs that
have empty child_fields, the code must treat group_id == field_id to
preserve that mapping.
- Bug fix (resolves #46594): SegmentLoadInfo now normalizes
field_binlog.child_fields() into a vector and falls back to using
field_id as the single child group when child_fields is empty; the same
normalization is applied for both current and new-info paths, ensuring
legacy v1 binlogs are discovered and included in Load/ComputeDiff
results so segments load correctly.
- Logic simplified: removed the implicit assumption that child_fields is
always present by centralizing a single normalization/fallback step used
symmetrically for both diff paths, avoiding ad-hoc special-casing and
unifying iteration over child groups.
- No data loss / no behavior regression: the fallback only activates
when child_fields is empty — non-legacy binlogs continue to use their
child_fields unchanged. Add/drop semantics are preserved because the
same normalization is applied to both sides of the diff. Unit tests
(v1-only, v4-only, mixed cases) were added to validate correctness;
LoadDiff::ToString() and extra logging are diagnostic only.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Cai Zhang <cai.zhang@zilliz.com>

---------

Signed-off-by: Congqi Xia <congqi.xia@zilliz.com>
2025-12-25 23:33:19 +08:00
..
2025-09-16 16:32:01 +08:00
2025-09-16 16:32:01 +08:00

WAL

wal package is the basic defination of wal interface of milvus streamingnode. wal use github.com/milvus-io/milvus/pkg/streaming/walimpls to implement the final wal service.

Project arrangement

  • wal
    • /: only define exposed interfaces.
    • /adaptor/: adaptors to implement wal interface from walimpls interface
    • /utility/: A utility code for common logic or data structure.
  • github.com/milvus-io/milvus/pkg/streaming/walimpls
    • /: define the underlying message system interfaces need to be implemented.
    • /registry/: A static lifetime registry to regsiter new implementation for inverting dependency.
    • /helper/: A utility used to help developer to implement walimpls conveniently.
    • /impls/: A official implemented walimpls sets.

Lifetime Of Interfaces

  • OpenerBuilder has a static lifetime in a programs:
  • Opener keep same lifetime with underlying resources (such as mq client).
  • WAL keep same lifetime with underlying writer of wal, and it's lifetime is always included in related Opener.
  • Scanner keep same lifetime with underlying reader of wal, and it's lifetime is always included in related WAL.

Add New Implemetation Of WAL

developper who want to add a new implementation of wal should implements the github.com/milvus-io/milvus/pkg/streaming/walimpls package interfaces. following interfaces is required:

  • walimpls.OpenerBuilderImpls
  • walimpls.OpenerImpls
  • walimpls.ScannerImpls
  • walimpls.WALImpls

OpenerBuilderImpls create OpenerImpls; OpenerImpls creates WALImpls; WALImpls create ScannerImpls. Then register the implmentation of walimpls.OpenerBuilderImpls into github.com/milvus-io/milvus/pkg/streaming/walimpls/registry package.

import "github.com/milvus-io/milvus/pkg/streaming/walimpls/registry"

var _ OpenerBuilderImpls = b{};
registry.RegisterBuilder(b{})

All things have been done.

Use WAL

import "github.com/milvus-io/milvus/internal/streamingnode/server/wal/registry"

name := "your builder name"
var yourCh *options.PChannelInfo

opener, err := registry.MustGetBuilder(name).Build()
if err != nil {
    panic(err)
}
ctx := context.Background()
logger, err := opener.Open(ctx, wal.OpenOption{
    Channel: yourCh  
})
if err != nil {
    panic(err)
}

Adaptor

package adaptor is used to adapt walimpls and wal together. common wal function should be implement by it. Such as:

  • lifetime management
  • interceptor implementation
  • scanner wrapped up
  • write ahead cache implementation