Backport PR #2904 to release/v1.7 for Add E2E test V2 Strategic testing framework for more maintainability #2908
Conversation
…2904) Signed-off-by: kpango <[email protected]>
Deploying vald with
|
| Latest commit: |
cc8720a
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://9887633d.vald.pages.dev |
| Branch Preview URL: | https://backport-release-v1-7-featur-tcvm.vald.pages.dev |
📝 WalkthroughWalkthroughThis pull request introduces extensive modifications across the codebase. New files and test cases are added for end‐to‐end testing, QUIC connections, gRPC stream handling, noise generation, and parameter parsing with generics. Core functions for error checking have been revised by replacing multiple error comparisons with concise helper functions (e.g. using Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant gRPC as "gRPC Client"
participant EH as "Error Handler (IsNot/IsAny)"
participant L as Logger
C->>gRPC: Send Request
gRPC->>EH: Evaluate error condition using IsNot / IsAny
EH-->>gRPC: Return error-check result
alt Error is critical
gRPC->>L: Log error details
gRPC-->>C: Return error response
else No critical error
gRPC-->>C: Return success response
end
Possibly related PRs
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| internal/net/option.go | ||
| internal/net/option_test.go | ||
| internal/net/quic/conn.go | ||
| internal/net/quic/conn_test.go |
There was a problem hiding this comment.
[file name cspell] reported by reviewdog 🐶
Unknown word (quic) Suggestions: [quia, quid, quin, quip, quit]
| internal/net/quic/conn.go | ||
| internal/net/quic/conn_test.go | ||
| internal/net/quic/listener.go | ||
| internal/net/quic/listener_test.go |
There was a problem hiding this comment.
[file name cspell] reported by reviewdog 🐶
Unknown word (quic) Suggestions: [quia, quid, quin, quip, quit]
|
[WARNING:INTCFG] Changes in |
github-actions
bot
added
area/discoverer
area/manager/index
area/filter/ingress
area/filter/egress
area/internal
type/ci
area/helm
area/makefile
area/agent/sidecar
area/tools/cli/loadtest
area/gateway/lb
area/gateway/filter
area/agent/core/faiss
area/agent/core/ngt
area/gateway/mirror
area/index/job/correction
area/index/job/creation
area/index/job/save
area/index/job/readreplica
size/XXXL
labels
|
[CHATOPS:HELP] ChatOps commands.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🧹 Nitpick comments (28)
apis/swagger/v1/vald/object.swagger.json (2)
17-18: Enhanced Documentation for/exists/{id}EndpointThe updated
"summary"and"description"now provide detailed guidance on status codes and troubleshooting steps. Please verify that the markdown formatting (including line breaks and the table syntax) renders correctly in the Swagger UI.
106-107: Consistent and Detailed Information for/object/{id.id}EndpointThe enhanced
"summary"and"description"now offer a thorough explanation of the API’s behavior, including a status code table and troubleshooting guidance. Ensure that the markdown (especially the table formatting) is displayed properly in the Swagger documentation.internal/errors/params.go (1)
20-20: Ensure Consistency in Error Definition
The new error variableErrArgumentParserNotFoundis concise and follows a common Go pattern. Please verify that theNewfunction (used to instantiate the error) is defined within this package or imported from a trusted source. Additionally, consider capitalizing the first letter of the error message (e.g."Argument parser not found") for consistency with common Go error conventions.charts/vald/values/dev.yaml (1)
49-49: New configuration parameter addition
The addition ofenable_statistics: trueunder thengtsection is clear and straightforward. Please verify that the underlying code correctly reads and uses this parameter and consider updating the documentation so that users understand its effect on the agent’s behavior.Makefile.d/minikube.mk (1)
28-29: Improved Minikube configuration for E2E testing.The changes explicitly configure and use Docker as the driver for Minikube, which improves consistency and reproducibility for the E2E testing framework. This aligns with the PR objective of enhancing the maintainability of the testing infrastructure.
Using Docker as the driver for Minikube is a good choice for CI/CD environments as it's typically faster and more resource-efficient than VM-based drivers. This should help speed up the E2E testing process and make it more reliable.
internal/core/algorithm/usearch/usearch_test.go (1)
670-670: Ensure proper nil mutex handling in future implementationThe changes set all mutex fields from
sync.RWMutex{}tonilin these commented-out test cases. When these TODO test cases are eventually implemented, ensure that proper nil checks are added before attempting to lock/unlock these mutexes to prevent potential nil pointer dereferences.Also applies to: 698-698, 932-932, 960-960, 1065-1065, 1097-1097, 1200-1200, 1231-1231, 1340-1340, 1372-1372, 1475-1475, 1506-1506, 1602-1602, 1630-1630
internal/errors/errors_test.go (3)
267-333: Typographical Error in Test Function NameThe test function is named
TestErrArgumentPraseFailedbut “Prase” appears to be a typo. Consider renaming it toTestErrArgumentParseFailedfor clarity and consistency with expected naming conventions.
1132-1196: Potential Typo in Test Function Name 'TestUnwarp'The function
TestUnwarplikely intends to verify the behavior of the unwrap functionality. Renaming it toTestUnwrapwould align it better with common naming conventions and reduce potential confusion.
1735-2088: Cleanup of Unimplemented Test BlocksThere is a large block of commented-out placeholder test functions (e.g., the
Test_is,TestUnwrap, and other related tests) starting with the “NOT IMPLEMENTED BELOW” comment. To improve maintainability and clarity:
- If these tests are planned for future implementation, please add explicit TODO comments outlining the intended test scenarios.
- Otherwise, consider removing the commented-out code to avoid cluttering the codebase.
apis/docs/v1/docs.md (5)
1372-1377: Mirror Service Overview Section Added
The addition of the “Overview” section for the Mirror service clearly communicates its purpose. However, the table separator row appears to contain extra columns that do not match the four header columns. This misalignment could affect markdown rendering and readability. Please verify and adjust the separator so that it exactly corresponds to the header columns.
1636-1644: Filter Service Overview Enhancement
The new “Overview” section for the Filter service is a useful addition. Note that the sentence “Vald Filter Gateway forward user request to user-defined ingress/egress filter components allowing user to run custom logic” has a minor grammatical issue. Consider changing it to “Vald Filter Gateway forwards user requests to user-defined ingress/egress filter components, allowing custom logic to be executed.”-Vald Filter Gateway forward user request to user-defined ingress/egress filter components allowing user to run custom logic. +Vald Filter Gateway forwards user requests to user-defined ingress/egress filter components, allowing custom logic to be executed.
1694-1700: Index Service Overview Improvement
Adding an overview for the Index service is a positive enhancement. To maintain grammatical consistency, please change “Represent the index manager service” to “Represents the index manager service.”-Represent the index manager service. +Represents the index manager service.
1715-1720: Insert Service Overview Enhancement
The overview section for the Insert service improves the clarity of the documentation. One point to note: ensure that within the associated method description the term “Inset RPC” is corrected to “Insert RPC” for consistency.-Overview Inset RPC is the method to add a new single vector. +Overview Insert RPC is the method to add a new single vector.
1372-1970: General Consistency and Grammar Check on Overview Sections
Multiple service sections now include added “Overview” segments. This consistent approach greatly improves the overall readability and usability of the documentation. Please do a pass on all newly added overview texts to ensure uniform tone, correct grammatical verb forms (e.g., “forwards” instead of “forward”, “Represents” instead of “Represent”), and overall alignment of table formatting.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
1416-1416: Spaces inside emphasis markers
null(MD037, no-space-in-emphasis)
1416-1416: Spaces inside emphasis markers
null(MD037, no-space-in-emphasis)
1420-1420: Spaces inside emphasis markers
null(MD037, no-space-in-emphasis)
1420-1420: Spaces inside emphasis markers
null(MD037, no-space-in-emphasis)
1514-1514: Bare URL used
null(MD034, no-bare-urls)
1600-1600: Bare URL used
null(MD034, no-bare-urls)
1600-1600: Reference links and images should use a label that is defined
Missing link or image reference definition: "google.rpc.code.permissiondenied"(MD052, reference-links-images)
1624-1624: Link fragments should be valid
null(MD051, link-fragments)
internal/iter/iter.go (5)
17-18: Package naming could be clearerThe package declaration appears in two lines, with the comment line 17 saying "package iter" and the actual declaration on line 18. This is redundant and potentially confusing.
-// package iter package iter
20-23: Consider explicit import comment for standard library iter packageThe import of the standard library
iterpackage could be confusing since it has the same name as the current package. Consider adding an explicit comment to clarify that this is the standard library iterator package.import ( "context" - "iter" + "iter" // Standard library iterator package )
96-98: Add documentation for Seq methodUnlike other methods, the
Seqmethod lacks proper documentation explaining its purpose and behavior. Since it delegates toValues, a clear comment would help users understand why both methods exist.+// Seq returns an iterator sequence (iter.Seq) of values, equivalent to Values. func (c *cycle[_, E]) Seq(ctx context.Context) iter.Seq[E] { return c.Values(ctx) }
132-143: Add documentation for ForEach methodThe
ForEachmethod lacks documentation explaining its purpose and behavior. Since this is a key method of the iterator interface, it should have clear documentation like the other methods.+// ForEach executes the provided function on each element in the iterator. +// The iteration stops if the function returns false or the context is canceled. func (c cycle[_, E]) ForEach(ctx context.Context, fn func(uint64, E) bool) { for i := uint64(0); i < c.num; i++ { select { case <-ctx.Done(): return default: } if !fn(i, c.At(i)) { return } } }
145-147: Add documentation for Raw methodThe
Rawmethod lacks documentation explaining what it returns and why someone might use it.+// Raw returns the original underlying array/slice without any modifications. func (c cycle[S, _]) Raw() S { return c.array }internal/errors/k8s.go (1)
43-45: Inconsistent error message capitalizationThe error messages for
ErrUndefinedNamespaceandErrUndefinedServicestart with uppercase "Undefined", unlike the other error messages that use lowercase. This inconsistency affects error message formatting.- ErrUndefinedNamespace = New("Undefined namespace") + ErrUndefinedNamespace = New("undefined namespace") - ErrUndefinedService = New("Undefined service") + ErrUndefinedService = New("undefined service")internal/net/grpc/option_test.go (2)
532-3344: Consider implementing the templated test cases.All test functions have TODO comments for test cases. As part of the strategic testing framework improvements, consider adding actual test cases to validate the behavior of these gRPC options.
532-3344: Opportunity for test structure refactoring.The test structure is highly repetitive with similar type definitions and setup code across all functions. Consider refactoring common setup code into helper functions to reduce duplication and improve maintainability.
+ // Create a common test setup function that handles the repetitive parts + func setupOptionTest[T any, R any](t *testing.T, args T, want R, testFunc func(T) Option) { + // Common test setup code + }.gitfiles (1)
512-512: Consider adding more documentation to the testing frameworkWhile the testing framework itself is well-structured, consider adding documentation that explains how to use it effectively, especially for new contributors. This aligns with the PR author's recommendation to add more documentation on the new E2E testing framework.
Also applies to: 825-832
apis/swagger/v1/vald/search.swagger.json (1)
15-22: Enhanced Summary for LinearSearch EndpointThe updated
"summary"and"description"now provide a clear, detailed overview of the LinearSearch RPC. The inclusion of a status code table and troubleshooting information is very helpful. Please verify that the markdown elements—such as the horizontal delimiters (---) and status code tables—render as expected in your Swagger UI.apis/swagger/v1/vald/insert.swagger.json (1)
15-20: Improve Summary for Insert EndpointThe new summary for the
/insertendpoint details the RPC functionality and presents an informative status code table. However, note a small typographical error: “Inset RPC” should be corrected to “Insert RPC” for accuracy.apis/swagger/v1/vald/filter.swagger.json (1)
15-25: Refined Summary for InsertObject EndpointThe updated summary for the
/insert/objectendpoint now clearly describes how objects are inserted via the Vald Filter Gateway. The status code table is precise. For uniformity with other endpoints, consider adding a brief"description"field if needed in future revisions.internal/net/grpc/server_test.go (2)
29-29: Document purpose of side-effect importThe import
_ "google.golang.org/grpc/encoding/proto"is being used for its side effects only. Consider adding a comment to explain why this import is necessary.- _ "google.golang.org/grpc/encoding/proto" + // Import proto encoding package for its initialization side effects only + _ "google.golang.org/grpc/encoding/proto"
836-1176: Consider removing or isolating commented test templatesThese commented test templates add significant clutter to the codebase without providing immediate value. Consider:
- Removing them and tracking the planned tests in your issue tracker
- Moving them to a separate file marked as a template
- If keeping them is necessary, add a comment explaining their purpose and when they'll be implemented
This would improve code readability while still maintaining your test development plans.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (31)
apis/grpc/v1/agent/core/agent.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/agent/sidecar/sidecar.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/discoverer/discoverer.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/egress/egress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/ingress/ingress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/meta/meta.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/payload/payload.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/rpc/errdetails/error_details.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goexample/client/go.sumis excluded by!**/*.sumgo.sumis excluded by!**/*.sumrust/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (107)
.gitfiles(15 hunks).github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/security_issue_report.md(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks).github/workflows/_docker-image.yaml(1 hunks).github/workflows/_release-pr.yaml(1 hunks).github/workflows/build-binaries.yaml(1 hunks).github/workflows/build-protobuf.yaml(1 hunks).github/workflows/chatops.yaml(5 hunks).github/workflows/codeql-analysis.yml(2 hunks).github/workflows/coverage.yaml(1 hunks).github/workflows/e2e-chaos.yaml(4 hunks).github/workflows/e2e-code-bench-agent.yaml(2 hunks).github/workflows/e2e-max-dim.yaml(1 hunks).github/workflows/e2e-profiling.yaml(1 hunks).github/workflows/e2e.yaml(8 hunks).github/workflows/format.yaml(3 hunks).github/workflows/fossa.yaml(1 hunks).github/workflows/helm-lint.yaml(3 hunks).github/workflows/helm.yaml(2 hunks).github/workflows/reviewdog-k8s.yaml(3 hunks).github/workflows/reviewdog.yaml(2 hunks).github/workflows/test-hack.yaml(1 hunks).github/workflows/unit-test-rust.yaml(1 hunks).github/workflows/unit-test.yaml(3 hunks).github/workflows/update-deps.yaml(1 hunks)Makefile(8 hunks)Makefile.d/e2e.mk(1 hunks)Makefile.d/functions.mk(1 hunks)Makefile.d/minikube.mk(1 hunks)Makefile.d/tools.mk(2 hunks)apis/docs/v1/docs.md(10 hunks)apis/swagger/v1/mirror/mirror.swagger.json(1 hunks)apis/swagger/v1/vald/filter.swagger.json(8 hunks)apis/swagger/v1/vald/flush.swagger.json(1 hunks)apis/swagger/v1/vald/index.swagger.json(5 hunks)apis/swagger/v1/vald/insert.swagger.json(2 hunks)apis/swagger/v1/vald/object.swagger.json(4 hunks)apis/swagger/v1/vald/remove.swagger.json(3 hunks)apis/swagger/v1/vald/search.swagger.json(8 hunks)apis/swagger/v1/vald/update.swagger.json(3 hunks)apis/swagger/v1/vald/upsert.swagger.json(2 hunks)charts/vald/values/dev.yaml(1 hunks)cmd/index/job/deletion/main_test.go(1 hunks)dockers/agent/core/agent/Dockerfile(1 hunks)dockers/agent/core/faiss/Dockerfile(1 hunks)dockers/agent/core/ngt/Dockerfile(1 hunks)dockers/agent/sidecar/Dockerfile(1 hunks)dockers/binfmt/Dockerfile(1 hunks)dockers/buildbase/Dockerfile(1 hunks)dockers/buildkit/Dockerfile(1 hunks)dockers/buildkit/syft/scanner/Dockerfile(1 hunks)dockers/ci/base/Dockerfile(1 hunks)dockers/dev/Dockerfile(1 hunks)dockers/discoverer/k8s/Dockerfile(1 hunks)dockers/example/client/Dockerfile(1 hunks)dockers/gateway/filter/Dockerfile(1 hunks)dockers/gateway/lb/Dockerfile(1 hunks)dockers/gateway/mirror/Dockerfile(1 hunks)dockers/index/job/correction/Dockerfile(1 hunks)dockers/index/job/creation/Dockerfile(1 hunks)dockers/index/job/deletion/Dockerfile(1 hunks)dockers/index/job/readreplica/rotate/Dockerfile(1 hunks)dockers/index/job/save/Dockerfile(1 hunks)dockers/index/operator/Dockerfile(1 hunks)dockers/manager/index/Dockerfile(1 hunks)dockers/operator/helm/Dockerfile(1 hunks)dockers/tools/benchmark/job/Dockerfile(1 hunks)dockers/tools/benchmark/operator/Dockerfile(1 hunks)dockers/tools/cli/loadtest/Dockerfile(1 hunks)example/client/go.mod(2 hunks)example/client/go.mod.default(1 hunks)go.mod(14 hunks)hack/go.mod.default(4 hunks)internal/backoff/backoff.go(2 hunks)internal/backoff/backoff_test.go(1 hunks)internal/backoff/option.go(0 hunks)internal/backoff/option_test.go(0 hunks)internal/client/v1/client/discoverer/discover.go(1 hunks)internal/client/v1/client/discoverer/discover_test.go(5 hunks)internal/config/benchmark_test.go(4 hunks)internal/config/config.go(2 hunks)internal/config/config_test.go(1 hunks)internal/config/grpc.go(1 hunks)internal/config/index_deleter_test.go(1 hunks)internal/core/algorithm/usearch/usearch_test.go(16 hunks)internal/db/nosql/cassandra/option_test.go(8 hunks)internal/errors/errors.go(2 hunks)internal/errors/errors_test.go(1 hunks)internal/errors/k8s.go(1 hunks)internal/errors/params.go(1 hunks)internal/file/file.go(3 hunks)internal/file/file_test.go(1 hunks)internal/info/info_test.go(17 hunks)internal/iter/iter.go(1 hunks)internal/net/dialer_test.go(1 hunks)internal/net/grpc/client.go(13 hunks)internal/net/grpc/errdetails/errdetails.go(6 hunks)internal/net/grpc/metadata_test.go(1 hunks)internal/net/grpc/option.go(1 hunks)internal/net/grpc/option_test.go(46 hunks)internal/net/grpc/pool/option.go(1 hunks)internal/net/grpc/pool/option_test.go(6 hunks)internal/net/grpc/pool/pool.go(6 hunks)internal/net/grpc/pool/pool_bench_test.go(2 hunks)internal/net/grpc/server_test.go(2 hunks)internal/net/grpc/status/status.go(1 hunks)
⛔ Files not processed due to max files limit (46)
- internal/net/grpc/status/status_test.go
- internal/net/grpc/stream.go
- internal/net/grpc/stream_test.go
- internal/net/http/client/client.go
- internal/net/http/client/client_test.go
- internal/net/http/client/option_test.go
- internal/net/net.go
- internal/net/net_test.go
- internal/net/quic/conn_test.go
- internal/net/quic/listener_test.go
- internal/params/option.go
- internal/params/option_test.go
- internal/params/params.go
- internal/params/params_test.go
- internal/rand/rand.go
- internal/runner/runner.go
- internal/servers/server/option_test.go
- internal/servers/server/server.go
- internal/servers/servers.go
- internal/sync/errgroup/group.go
- internal/sync/errgroup/group_test.go
- internal/test/data/vector/gen.go
- internal/test/data/vector/noise/noise.go
- internal/test/data/vector/noise/noise_test.go
- internal/test/data/vector/noise/option.go
- internal/test/data/vector/noise/option_test.go
- internal/test/mock/server_stream.go
- internal/timeutil/time.go
- internal/timeutil/time_test.go
- k8s/agent/ngt/configmap.yaml
- k8s/discoverer/deployment.yaml
- k8s/gateway/gateway/lb/deployment.yaml
- k8s/gateway/gateway/mirror/deployment.yaml
- k8s/index/operator/deployment.yaml
- k8s/manager/index/deployment.yaml
- pkg/agent/core/faiss/service/faiss.go
- pkg/agent/core/ngt/service/ngt.go
- pkg/agent/core/ngt/service/ngt_test.go
- pkg/agent/core/ngt/service/option_test.go
- pkg/discoverer/k8s/service/discover_test.go
- pkg/gateway/lb/handler/grpc/aggregation_test.go
- pkg/gateway/lb/handler/grpc/handler_test.go
- pkg/gateway/mirror/service/mirror.go
- pkg/index/job/deletion/config/config_test.go
- pkg/index/job/deletion/service/deleter_test.go
- pkg/index/job/deletion/service/options_test.go
💤 Files with no reviewable changes (2)
- internal/backoff/option.go
- internal/backoff/option_test.go
🧰 Additional context used
🧠 Learnings (1)
.gitfiles (1)
Learnt from: datelier
PR: vdaas/vald#2807
File: rust/bin/agent/src/handler/object.rs:36-38
Timestamp: 2025-04-01T12:29:37.305Z
Learning: In Rust code for Vald handlers, avoid using unwrap() on Option types. Instead, handle None values explicitly by returning appropriate error statuses to maintain robustness.
🧬 Code Definitions (4)
internal/net/grpc/status/status.go (2)
internal/errors/errors.go (1)
Is(163-168)internal/net/grpc/codes/codes.go (1)
Code(22-22)
internal/config/grpc.go (1)
internal/net/grpc/option.go (1)
WithOldConnCloseDelay(656-663)
internal/net/grpc/client.go (3)
internal/errors/errors.go (3)
IsNot(182-192)IsAny(170-180)Is(163-168)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/net/grpc/status/status.go (3)
Error(125-127)FromError(185-257)Is(48-50)
internal/net/grpc/pool/pool.go (5)
internal/net/grpc/client.go (2)
ClientConn(50-50)DialOption(49-49)internal/net/net.go (4)
Conn(41-41)Parse(188-222)SplitHostPort(242-264)DefaultResolver(88-88)internal/net/grpc/status/status.go (3)
Is(48-50)Errorf(129-131)Error(125-127)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/backoff/backoff.go (1)
Backoff(58-61)
🔇 Additional comments (211)
dockers/buildkit/syft/scanner/Dockerfile (1)
20-21: Minor Change: Newline AdditionThe only change in this Dockerfile is the addition of a newline at the end, which is a best practice for file termination and does not affect functionality.
dockers/gateway/lb/Dockerfile (1)
89-90: Consistent Newline in ENTRYPOINT InstructionThe change ensures that the
ENTRYPOINTinstruction now ends with a newline. This improves file formatting and avoids potential issues with file concatenation in some build environments without altering the container's behavior.internal/backoff/backoff_test.go (1)
63-63: Configuration change to align with defaultOptionsThe test's expected value for
errLoghas been updated fromtruetofalseto reflect the removal ofWithEnableErrorLog()from thedefaultOptionsslice ininternal/backoff/option.go. This ensures the test properly validates the new default behavior where error logging is disabled by default.internal/backoff/backoff.go (2)
20-23: Addition of maps package for improved map operationsThe
mapspackage import is added to support the refactored implementation of theMetricsfunction.
244-244: Improved code clarity using maps.CloneThe implementation has been refactored to use
maps.Clone(metrics)instead of manually copying the map elements. This improves code readability and maintainability while potentially offering better performance.dockers/buildbase/Dockerfile (1)
19-21: Formatting Update: Newline Addition
The change in this Dockerfile is limited to a formatting update—a newline (with theFROM ubuntu:devel AS builderinstruction on line 20) has been added at the end of the file. This change does not affect functionality.dockers/binfmt/Dockerfile (1)
19-21: Consistent Formatting in Dockerfile
Similar to the buildbase Dockerfile, this file now ends with a newline. The base image instruction (FROM tonistiigi/binfmt:master AS builder) remains unchanged, preserving the intended functionality.dockers/buildkit/Dockerfile (1)
19-21: Formatting Update: Trailing Newline
This Dockerfile now includes a trailing newline after theFROM moby/buildkit:master AS builderinstruction. Such formatting changes improve consistency across Dockerfiles and do not impact the build process.dockers/ci/base/Dockerfile (1)
129-131: ENTRYPOINT Re-introduction and Formatting Check
The Dockerfile shows that theENTRYPOINT ["/bin/bash"]instruction was removed and then re-added (line 130) with no changes in its content. This appears to be a formatting or reordering update rather than a functional change. Ensure that this change was intentional and that no unintended modifications (like extra spaces or changes in the command semantics) have been introduced.dockers/dev/Dockerfile (1)
143-144: Non-functional USER directive update
The re-introduction ofUSER root:rootat the end of the Dockerfile is functionally identical to the earlier specification. Although there is no behavioral change, please confirm this reordering aligns with your intended Dockerfile structure and team style guidelines.dockers/operator/helm/Dockerfile (1)
109-110: Consistent ENTRYPOINT formatting
The updatedENTRYPOINT ["/usr/bin/helm-operator", "run", "--watches-file=/opt/helm/watches.yaml"]appears to be a reformatting change without any modification to functionality. This update helps standardize the Dockerfile formatting.dockers/agent/core/ngt/Dockerfile (1)
98-98: ENTRYPOINT formatting update
The change at the end of the file—updating theENTRYPOINT ["/usr/bin/ngt"]—is a non-functional formatting update. This aligns the Dockerfile with modern formatting practices, ensuring consistency across similar files.dockers/discoverer/k8s/Dockerfile (1)
89-90: Formatting update for ENTRYPOINT
The reformatting that results inENTRYPOINT ["/usr/bin/discoverer"]does not alter the command behavior. It simply cleans up the file’s trailing formatting. Ensure that this change remains consistent with other Dockerfiles in the repository.dockers/index/job/creation/Dockerfile (1)
89-89: Formatting Update: Consistent ENTRYPOINT DeclarationThe updated ENTRYPOINT line now explicitly ends with a newline, ensuring consistency in Dockerfile formatting. There is no functional change to the container startup command.
dockers/example/client/Dockerfile (1)
95-95: Minor Formatting Improvement: Newline AddedThe addition of a newline at the end of the ENTRYPOINT instruction enhances file readability and ensures consistency with other Dockerfiles. No changes to functionality.
dockers/agent/core/faiss/Dockerfile (1)
99-99: Formatting Consistency: ENTRYPOINT StatementUpdating the ENTRYPOINT line to include a terminating newline makes the Dockerfile formatting consistent across the project. The operational behavior remains unchanged.
dockers/agent/sidecar/Dockerfile (1)
88-88: Consistent Formatting: ENTRYPOINT DeclarationThe re-addition of the ENTRYPOINT line with a newline ensures uniform formatting in the Dockerfile. This change does not impact the container’s runtime behavior.
dockers/tools/cli/loadtest/Dockerfile (1)
96-96: Standardization: ENTRYPOINT FormattingThe updated ENTRYPOINT for the loadtest tool includes a newline at the end, aligning its style with other Dockerfiles. This is purely a formatting adjustment with no effect on functionality.
dockers/index/job/save/Dockerfile (1)
89-90: Minor Formatting Update on ENTRYPOINT
The change consists of reformatting the Dockerfile by adding (or ensuring) a newline after the ENTRYPOINT instruction. There is no alteration in functionality.dockers/gateway/mirror/Dockerfile (1)
89-90: Consistent Formatting for ENTRYPOINT
The updated ENTRYPOINT instruction now follows the consistent formatting pattern (including the newline at the end). This is a cosmetic change with no impact on the runtime behavior of the container.dockers/index/job/deletion/Dockerfile (1)
89-90: ENTRYPOINT Formatting Consistency for Index Deletion Job
The modification introduces a newline after the ENTRYPOINT command, ensuring consistency with similar Dockerfiles. The functionality remains unchanged.dockers/agent/core/agent/Dockerfile (1)
97-98: Reapplied ENTRYPOINT with Correct Formatting
The Dockerfile now reintroduces the same ENTRYPOINT instruction with proper formatting (including a terminating newline). This change is purely stylistic and does not affect the container’s operation.dockers/index/operator/Dockerfile (1)
89-90: Standardized ENTRYPOINT Formatting
The updated ENTRYPOINT line now ends with a newline, aligning its formatting with other Dockerfiles in the project. There is no functional change; it simply improves consistency across the codebase.dockers/tools/benchmark/operator/Dockerfile (1)
89-90: ENTRYPOINT Formatting Consistency.The
ENTRYPOINT ["/usr/bin/operator"]instruction is functionally unchanged; the addition of a trailing newline improves consistency across Dockerfiles.dockers/gateway/filter/Dockerfile (1)
89-90: ENTRYPOINT Formatting Consistency.The
ENTRYPOINT ["/usr/bin/filter"]line remains the same functionally with a newline now present at the end of the file, aligning its formatting with other Dockerfiles.dockers/tools/benchmark/job/Dockerfile (1)
96-97: ENTRYPOINT Formatting Update for Job Service.The
ENTRYPOINT ["/usr/bin/job"]directive is unchanged in behavior. The formatting update—with the addition of a newline at the end—enhances consistency within the Dockerfile standards across the project.internal/net/grpc/option.go (1)
656-664: Renaming for Clarity and Consistency.The function has been renamed from
WithOldConnCloseDurationtoWithOldConnCloseDelayto better reflect its purpose. The implementation correctly assigns the given duration string tog.roccd. Please verify that all callers have been updated to use the new name to maintain consistency across the codebase.dockers/index/job/correction/Dockerfile (1)
89-90: ENTRYPOINT Formatting Consistency.The
ENTRYPOINT ["/usr/bin/index-correction"]instruction remains functionally identical while the added newline at the end of the file ensures uniform formatting with other Dockerfiles.dockers/index/job/readreplica/rotate/Dockerfile (1)
89-89: LGTM: Consistent ENTRYPOINT declaration.The ENTRYPOINT directive is correctly declared, ensuring the container will execute the readreplica-rotate binary when started.
Makefile.d/tools.mk (2)
216-216: Improved CMake configuration for zlib build.Adding the CMake policy version minimum ensures consistent build behavior across different environments by explicitly setting the policy version.
245-245: Improved CMake configuration for hdf5 build.Similarly to the zlib configuration, setting the minimum CMake policy version for HDF5 build ensures consistent behavior across different environments.
internal/config/benchmark_test.go (2)
22-22: Added Meta field to support metadata in benchmark targets.The addition of the Meta map field enhances the BenchmarkTarget structure to support arbitrary metadata, which is valuable for the E2E testing framework improvements mentioned in the PR objectives.
49-49: Properly initialized Meta field in test cases.The Meta field is consistently initialized to nil in test cases, maintaining compatibility with existing tests while supporting the new field.
Also applies to: 70-70, 103-103
apis/swagger/v1/mirror/mirror.swagger.json (1)
17-17: Great improvement to API documentation!Adding an "Overview" section and "Status Code" table enhances the API documentation clarity and completeness.
dockers/manager/index/Dockerfile (1)
89-89: Ensures Dockerfile has proper EOL character.This minor formatting change ensures the file ends with a newline, which is a good practice for text files.
apis/swagger/v1/vald/index.swagger.json (1)
17-17: Consistent enhancement of API documentation.Prepending "Overview" to each summary text improves documentation structure and readability, keeping documentation format consistent across all API endpoints.
Also applies to: 38-38, 59-59, 80-80, 101-101
Makefile.d/functions.mk (1)
134-154: Well-implemented V2 E2E testing function.This new function
run-v2-e2e-crud-testproperly supports the V2 end-to-end strategic testing framework mentioned in the PR objectives. The implementation appropriately sets environment variables and executes tests with the right flags and parameters.The function mirrors the existing E2E test pattern while pointing to the new V2 test structure, which helps maintain consistency in the build system.
Makefile.d/e2e.mk (1)
22-25: LGTM: New V2 E2E testing targetThe addition of the new
e2e/v2target aligns well with the PR objectives, introducing support for the V2 strategic testing framework while maintaining backward compatibility with existing E2E test targets.internal/net/grpc/pool/pool_bench_test.go (1)
120-120: Improved benchmark methodologyReplacing the traditional for-loops with
b.Loop()is a good improvement. This method is specifically designed for benchmarks and provides more accurate measurements by giving the testing framework better control over benchmark execution.Also applies to: 144-144
internal/config/grpc.go (1)
186-186: Function name update for consistencyThe function has been renamed from
WithOldConnCloseDurationtoWithOldConnCloseDelayfor better terminology consistency. This is a straightforward change that maintains the same functionality while improving naming clarity.internal/config/config_test.go (1)
999-1003: Test case name and expectation now align with the new functionality.The test case has been updated to verify the behavior when a file path doesn't exist, with the expectation of returning an empty result - which matches the test name "return empty when not exists file contents".
This is a positive change that makes the test more explicit about the expected behavior of
GetActualValuewhen dealing with non-existent files.internal/errors/errors.go (3)
86-88: Well-structured error generator for unimplemented features.This new error generator follows the same pattern as other error generators in the file and provides a clear message format for unimplemented features.
170-180: Good addition of theIsAnyutility function.This function enhances error handling by allowing checks against multiple error types. It properly handles edge cases (nil error or empty targets) and follows good practice by leveraging the existing
Isfunction.
182-192: Useful complement with theIsNotfunction.This function provides the opposite check of
IsAnyand follows the same pattern. The handling of the nil error case is particularly good - returningerr != nilwhen no targets are provided.internal/net/grpc/errdetails/errdetails.go (4)
80-82: Good addition of theDetailsstruct for multiple error details.This struct provides a clean way to encapsulate and serialize multiple
Detailobjects, which enhances the error handling capabilities for gRPC status.
165-172: Improved error handling with default case for unknown message types.The addition of a default case that uses
protojson.Marshalmakes the code more robust when dealing with message types not explicitly defined in the switch statement. The error handling with logging is also a good practice for debugging.
317-322: Enhanced serialization for multiple messages.The updates to the
Serializefunction use the newDetailsstruct for multiple messages and properly check for nil byte slices, making the code more robust.
416-421: Added flexibility for handling unknown message types.The default case in
AnyToErrorDetailattempts to unmarshal unknown types, increasing the function's flexibility and making it more robust for the testing framework.internal/errors/errors_test.go (1)
1-264: Overall Test Structure and ReadabilityThe file demonstrates an excellent use of table-driven tests and helper functions (such as the
defaultCheckFunc) across various error-related test cases. This consistent approach helps ensure thorough coverage of different error scenarios and edge cases. Just ensure that any placeholder test code is eventually addressed or removed.internal/db/nosql/cassandra/option_test.go (7)
538-538: Error handling simplified with direct error creation.The error message creation has been changed to use a simpler approach with direct error creation rather than a composite error.
1524-1525: Error message simplified for better readability.The error message for invalid duration now uses a more straightforward error structure, making it easier to understand the failure reason.
1616-1617: Consistent error structure applied for duration validation.This change maintains consistency with other similar error messages in the file, using the same simplified error pattern.
1708-1709: Error handling improved in reconnection policy tests.The error creation pattern has been standardized across different types of timeout tests.
1875-1876: Socket keepalive error handling simplified.The change matches the general refactoring approach in this file to simplify error messages.
2980-2981: Schema agreement timeout error simplified.This change follows the pattern of error handling simplification throughout the test file.
3070-3071: Reconnect interval error handling simplified.The error message creation has been made more direct, following the same pattern as other time-related error handling in this test file.
internal/file/file.go (3)
259-259: Improved error handling with standardized approachThe change from direct comparison
err != nil && err != io.EOFto usingerrors.IsNot(err, io.EOF)is a good refactoring that leverages the error handling utility functions for better code consistency.
374-391: Well-implemented path resolution functionThe new
AbsolutePathfunction centralizes path resolution logic, providing a robust implementation that handles empty paths, tries multiple approaches to resolve relative paths, and ensures the result is cleaned.The function follows good practices:
- Handles edge cases (empty path)
- Attempts resolution using current working directory
- Falls back to filepath.Abs if needed
- Cleans the final path to remove redundancies
This abstraction improves maintainability by providing a single, consistent approach to path resolution throughout the codebase.
564-564: Good refactoring to use the new AbsolutePath functionRefactoring the
Joinfunction to use the newly createdAbsolutePathfunction improves code maintainability by centralizing path resolution logic.internal/info/info_test.go (3)
341-342: Field added to align with implementation changesThe
valdReplacer *strings.Replacerfield has been added to thefieldsstruct, correctly updating the test structure to match changes in the production code.
427-429: Correctly updated initialization structureThe initialization of the
infostruct has been properly updated to include the newvaldReplacerfield, maintaining consistency with the changes to the struct definition.
996-1094:❓ Verification inconclusive
New test function added for ShortString method
A well-structured test function has been added for the
StackTrace.ShortStringmethod, following the same pattern as other tests in the file. This enhances test coverage for the new functionality.Note that the test cases are currently marked as TODOs. Consider implementing concrete test cases to verify the behavior of the
ShortStringmethod.
🏁 Script executed:
#!/bin/bash # Check if ShortString method is implemented in the info.go file echo "Checking for ShortString method implementation:" rg -A 2 "func \(\*?StackTrace\) ShortString\(" internal/info/Length of output: 168
Attention: Verify the ShortString method implementation
The new test function for the
StackTrace.ShortStringmethod appears well structured and follows the conventions used by other tests. However, our repository search did not locate any implementation of theShortStringmethod (no output was produced when searching in theinternal/info/directory). Please verify whether theShortStringmethod implementation exists in another location or is planned to be added. Also, note that the test cases are still marked as TODOs, so concrete validations should be implemented to fully verify the behavior of the method.
- Review file:
internal/info/info_test.go(test function forShortStringis provided but commented out).- Action Required: Confirm that the
ShortStringmethod is implemented in the codebase (or update the test if the implementation exists elsewhere) and complete the test cases.internal/net/grpc/pool/option_test.go (2)
449-449: Improved parameter naming for clarityChanged parameter name from
flgtoenableinWithResolveDNSfunction test, which enhances code readability by using a more descriptive parameter name. This change aligns with the function implementation.Also applies to: 474-474, 493-493, 524-524
872-872: Function renamed for semantic clarityThe test function and method call have been renamed from
WithOldConnCloseDurationtoWithOldConnCloseDelay, which better represents the purpose of the functionality. This naming shift from "duration" to "delay" more clearly communicates the intention of the parameter.Also applies to: 949-949
internal/config/config.go (4)
66-66: Enhanced flexibility with generic type parameterThe
Readfunction has been updated to use a generic type parameterT anyinstead ofany, which provides better type safety and flexibility. This change maintains the function's behavior while making it more versatile.
99-115: Improved type flexibility for string handling functionsThe
GetActualValuefunction now uses a generic type parameterT ~stringinstead of concrete strings, allowing it to work with any string-like type. The implementation correctly handles the type conversions between the generic type and string where necessary.This change enhances code reusability while maintaining the function's original behavior.
120-125: Made GetActualValues function genericThe
GetActualValuesfunction has been updated to work with slices of any string-like type through the generic type parameterT ~string. This change aligns with the updates toGetActualValueand maintains consistency in the API.
128-130: Added generic support to helper functionThe
checkPrefixAndSuffixhelper function now uses generic type parameterT ~string, consistent with the other string-related functions. The implementation correctly converts the generic types to strings for the operations.apis/docs/v1/docs.md (1)
1677-1682: Flush Service Overview Addition
The overview for the Flush service is concise and clearly states its responsibility for removing all indexed and uncommitted vectors from thevald-agent. This change adds clarity without introducing any issues.internal/iter/iter.go (5)
28-38: Good interface design with clear abstractionsThe
Cycleinterface is well-designed with a clear set of methods that provide a flexible API for working with sequences of elements. The variety of iteration methods (Seq, Seq2, Values, Indexes, ForEach) gives clients multiple options for traversing and processing collections.
40-49: Well-structured implementation with clear field documentationThe
cyclestruct is well-structured with clear documentation for each field. The design enables efficient on-the-fly transformations through the optionalmodFuncfunction.
51-68: Robust initialization with proper validationThe
NewCyclefunction provides robust initialization with proper input validation for nil and empty slices. The calculation of the starting index using modulo arithmetic is a good approach for handling the offset.
70-78: Element access with efficient transformationThe
Atmethod is well-implemented, providing element access with efficient transformation via the optional modFunc. The modulo calculation ensures proper wrapping behavior when accessing elements.
80-130: Well-implemented sequence generators with context cancellation supportThe sequence generation methods (
Seq2,Values,Indexes) are well-implemented with proper context cancellation support. This ensures that iteration can be safely interrupted when needed.internal/errors/k8s.go (3)
20-22: Appropriate change to variable declaration styleThe change from a single variable declaration to a grouped variable declaration improves code organization, especially with the addition of multiple new error variables.
23-25: Well-implemented error factory for pod status errorsThe
ErrPodIsNotRunningfunction provides a clear and specific error message that includes the pod namespace and name, which is helpful for debugging Kubernetes-related issues.
35-37: Good error factory implementation for unsupported resource typesThe
ErrUnsupportedKubernetesResourceTypefunction provides useful type information in the error message, which will help with debugging unsupported resource types.internal/net/grpc/pool/option.go (8)
30-38: Improved variable naming in default optionsThe renaming from
WithOldConnCloseDurationtoWithOldConnCloseDelayimproves clarity and consistency with the field naming pattern.
41-53: Enhanced error handling in WithAddr functionThe
WithAddrfunction now properly handles address parsing usingnet.SplitHostPortand sets the host and port accordingly. This is a significant improvement in handling edge cases.
56-72: Improved host and port assignmentThe
WithHostandWithPortfunctions now directly assign values without unnecessary return statements, making the code cleaner and more straightforward.
92-97: Better parameter naming in WithResolveDNSRenaming the parameter from
flgtoenableimproves readability and self-documentation. The field name change fromresolveDNStoenableDNSLookupis also more descriptive.
99-106: Simplified WithBackoff functionThe
WithBackofffunction now directly assigns the backoff strategy without an unnecessary return statement, making the code cleaner.
108-116: Updated WithSize function for atomic storageThe function now stores the size in an atomic variable (
p.poolSize.Store(size)) which suggests proper handling of concurrent access.
118-125: More efficient DialOptions handlingThe simplified appending of dial options without unnecessary checks for empty slice improves code readability.
139-149: Improved naming for connection close delayThe function rename from
WithOldConnCloseDurationtoWithOldConnCloseDelayand corresponding field name changes improve consistency and clarity.apis/swagger/v1/vald/update.swagger.json (2)
17-18: Excellent enhanced API documentationThe updated summary for the
/updateendpoint now includes a comprehensive overview, detailed status code table, and troubleshooting information. This significantly improves the usability of the API documentation.
50-51: Well-structured API documentation with warningThe enhanced documentation for the
/update/multipleendpoint includes a clear warning about gRPC message size limitations, which is valuable information for API users. The consistent structure with status codes and troubleshooting information matches the other endpoints.Makefile (8)
163-163: Confirm the trade‐offs of-ffast-math.Switching from
-Ofastto-O3 -ffast-mathcan relax IEEE compliance and alter floating-point behavior. If your code depends on strict floating-point guarantees, consider verifying correctness or reverting to stricter flags.
167-167: Great addition of-lmfor HDF5 linkage.Linking the math library helps avoid missing symbol errors and aligns with HDF5’s dependencies.
169-169: Verify usage ofTEST_LDFLAGS.Replacing the direct combination of FAISS/HDF5 linker flags with
$(CGO_LDFLAGS)might require ensuring thatFAISS_LDFLAGSandHDF5_LDFLAGSare properly included inCGO_LDFLAGS.
355-356: New E2E variables introduced.The addition of
E2E_CONFIGandE2E_ADDRas configurable targets is a good approach for decoupling test parameters from the rest of the project.
470-476: Request verification on.gitfilesgeneration.Appending
git ls-filesoutput into.gitfilesmight unintentionally track extraneous files if the repository contains submodules or generated artifacts. Verify that only relevant files are captured.
552-553: Ensure consistent installation steps for goimports.Listing
goimports/installbeforefilesfosters a clear tooling‐then‐files approach in the format pipeline.
555-563: Parallel Go file formatting approach looks solid.Running golines, strictgoimports, goimports, crlfmt, and gofumpt in parallel can significantly speed up formatting. This pipeline is well‐structured.
571-580: Extending formatting to Go test files.Applying the same parallelized formatting flow to tests ensures consistent code style across the entire Go codebase.
apis/swagger/v1/vald/remove.swagger.json (3)
17-18: Rich documentation for/removeendpoint.Expanding the summary and adding a troubleshooting table significantly improves user clarity.
50-51: Thorough explanation for/remove/multiple.The added gRPC size limitation notice and status codes aid in diagnosing issues and align with best practices for multi‐item removal.
83-84: Detailed summary for/remove/timestamp.Highlighting the
ANDcondition for multiple timestamps and including a troubleshooting guide provides excellent clarity to consumers.internal/net/grpc/pool/pool.go (13)
17-20: Enhanced package‐level documentation.Describing the lock‐free re‐implementation, DNS lookup, and metrics collection features at the top level is helpful for integrators.
34-35: Check additional imports for potential duplication.Imports of both
codesandstatusfrominternal/net/grpcare appropriate here, but ensure they’re not duplicating symbols from the standard gRPC package if used concurrently.
43-44: Aliasing gRPC types for clarity.Defining
ClientConnandDialOptionas aliases keeps usage consistent throughout the package.
49-49: Interface comment updated.The
Conninterface’s doc comment is now aligned with the newly introduced methods. Good for code clarity.
51-60: Refined Conn interface methods.Incorporating the
context.Contextparameter fosters better timeout and cancellation handling, improving reliability in production.
82-121: Lock‐free connection close logic.The updated
Closemethod with periodic checks is a thoughtful approach to gracefully handle shutdown while respecting context cancellation.
387-394: Connecting logic with DNS fallback.The single vs. multiple IP paths effectively handle direct IP connections vs. DNS lookups. Ensuring fallback to a single target improves resiliency.
461-485: Reconnection strategy improvements.The
Reconnectmethod selectively re‐establishes connections, respecting DNS changes and overall health. This design balances efficiency with reliability.
487-513: Streamlined pool shutdown.
Disconnectnow collects errors and gracefully handles existing connections. This improves resource cleanup and helps avoid orphaned gRPC connections.
559-582: Robust round‐robin healthy connection retrieval.
getHealthyConntries up topoolSizetimes and refreshes connections if needed. This approach ensures minimal downtime.
584-595: Context‐aware function invocation withDo.Running user‐provided commands against a guaranteed healthy connection simplifies client usage while gracefully handling closed connections.
606-633: Overall pool health checking logic.Tracking healthy counts and storing them in a global sync map for metrics is a convenient approach; keep an eye on concurrency overhead.
740-770:isHealthyfunction thoroughly checks connectivity states.Including a fallback to trigger reconnection upon
IdleorConnectingis a solid approach to keep connections fresh, though repeated transitions should be monitored to avoid excessive churn.internal/net/grpc/option_test.go (4)
532-615: Function rename to improve test classification.The test function has been renamed from
TestWithDialOptionstoTestWithBackoffMaxDelaywith parameter type changed from[]grpc.DialOptiontostring. This change improves clarity by making the test name directly reflect what it's testing.
617-700: Organized test function naming and parameter structure.The restructuring of test functions creates a more logical organization focused on backoff-related functionalities. Test names now better reflect the specific option being tested, which improves maintainability and readability.
Also applies to: 702-785, 787-870, 872-955, 957-1040, 1042-1125, 1127-1210, 1212-1295
2581-3174: Added new test functions for comprehensive gRPC option coverage.New test functions for various gRPC options (WithAuthority, WithDisableRetry, WithIdleTimeout, etc.) improve test coverage and align with the enhanced E2E testing framework goals mentioned in the PR objectives.
3261-3344: Function rename for accuracy.Renamed
TestWithOldConnCloseDurationtoTestWithOldConnCloseDelayto better reflect the underlying parameter's purpose and align with naming conventions..gitfiles (8)
126-126: New Rust unit testing workflow addedThe addition of a dedicated workflow for Rust unit testing is appropriate given the new Rust components being introduced in this PR. This will ensure proper CI/CD coverage for the Rust codebase.
161-177: Comprehensive API documentation enhancementThe addition of these documentation files significantly improves the project's API documentation coverage. The structured approach with separate files for each API endpoint (filter, flush, index, etc.) will make it easier for developers to find specific API information.
488-488: QBG sample configuration addedThis sample configuration file aligns with the new QBG algorithm implementation in Rust (lines 1986-1990). Ensure this sample is properly documented to help users understand the configuration options.
863-863: Test coverage and error handling improvementsThese additions enhance the project's test coverage and error handling capabilities:
- New test for index deleter functionality
- New params error handling module
- QUIC connection and listener tests
These improvements align with the PR objectives of refactoring internal packages and improving error handling.
Also applies to: 1051-1051, 1274-1276
2035-2055: New V2 E2E strategic testing framework addedThis is the core feature of the PR, implementing a comprehensive end-to-end testing framework with:
- Configurable test assets (YAML configurations)
- Configuration and enumeration support
- CRUD, dataset, and various testing strategies
- HDF5 data handling
- Kubernetes integration with client, resources, rollout, and status management
- Port forwarding capabilities
The structure follows a well-organized pattern that should improve maintainability as mentioned in the PR objectives.
2067-2067: K3D version file addedThe addition of a K3D version file is appropriate for maintaining consistency in the Kubernetes development environment used for testing. This helps ensure reproducible test environments.
1088-1088: New iterator abstraction package addedThe addition of the
internal/iterpackage with theiter.gofile implements the iterator abstraction mentioned in the PR objectives. This should improve code reusability and provide a consistent pattern for iteration operations throughout the codebase.
1407-1410: Vector noise generation utilities addedThese new utilities for vector noise generation will be valuable for testing vector-based operations, particularly in the context of the new E2E testing framework. They provide tools for generating test data with controlled noise characteristics.
apis/swagger/v1/vald/search.swagger.json (7)
48-56: Updated Details for LinearSearchByID EndpointThe changes for the LinearSearchByID endpoint extend the description with troubleshooting tips and use HTML line break (
\u003cbr\u003e) elements for better formatting. The detailed status code table helps users quickly understand error responses.
80-88: Improved Summary for MultiLinearSearchByIDThe updated summary now clearly explains that multiple IDs can be handled in a single request. The markdown enhancements (using 1 to emphasize the request count) align well with other endpoints.
115-123: Clarified Overview for MultiLinearSearch EndpointThe revised summary and detailed troubleshooting information for the MultiLinearSearch endpoint provide a better user guide. The status code table is formatted consistently with other endpoints.
147-155: Expanded Overview for Search EndpointThe enhanced summary for the Search RPC now includes comprehensive status codes and troubleshooting details. This improved documentation should aid in faster diagnosis of issues.
180-188: Detailed Description for SearchByID EndpointThe updated summary and description offer an in‐depth explanation of the SearchByID RPC—with clear troubleshooting instructions and consistent formatting (including HTML
<br>for line breaks).
212-218: Enhanced MultiSearchByID Endpoint DocumentationThe revised summary and description now clearly outline the behavior of the multi-ID search request, with a well‐formatted status code table matching other endpoints’ style.
246-254: Comprehensive Overview for MultiSearch EndpointThe updated documentation for the MultiSearch RPC is clear and structured. The status code table and troubleshooting section are well designed, providing useful guidance in one consolidated view.
apis/swagger/v1/vald/insert.swagger.json (1)
48-55: Enhanced Documentation for MultiInsert EndpointThe updated summary and description for the
/insert/multipleendpoint now include information regarding message size limitations along with the comprehensive table of status codes. This makes the endpoint’s behavior much clearer to users.apis/swagger/v1/vald/upsert.swagger.json (2)
15-23: Enhanced Summary for Upsert EndpointThe revised summary for the
/upsertendpoint now effectively explains both the update and insert behaviors of the RPC. The detailed status code table and troubleshooting section directly support user guidance and error diagnostics.
48-55: Improved MultiUpsert Endpoint DocumentationThe new summary and description for the
/upsert/multipleendpoint are clear and provide essential details, including a notice about message size limitations and a comprehensive status code table.apis/swagger/v1/vald/filter.swagger.json (7)
47-55: Enhanced MultiInsertObject DocumentationThe new summary for the
/insert/object/multipleendpoint provides a comprehensive overview of the RPC, including the relevant status codes. It is consistent with the style used in other endpoints.
79-88: Detailed Summary for SearchObject EndpointThe revised summary for the
/search/objectendpoint is concise and benefits from a clear status code table, which improves overall clarity.
111-119: Improved StreamSearchObject Endpoint DocumentationFor the
/search/object/multipleendpoint, the updated summary explicitly mentions bidirectional streaming RPC and explains the independent nature of each search request–a valuable enhancement for API users.
143-150: Updated Overview for UpdateObject EndpointThe newly reworded summary for the
/update/objectendpoint now clearly conveys its purpose along with a detailed status code table, enhancing user comprehension.
175-179: Enhanced MultiUpdateObject Endpoint DetailsThe summary and accompanying description for
/update/object/multiplenow include a warning about gRPC message size limitations. This extra detail helps to set the right expectations for payload sizes.
209-217: Improved Summary for UpsertObject EndpointThe updated
"summary"for the/upsert/objectendpoint clearly communicates that the RPC can update an existing object or add a new one. The consistent presentation of the status code table reinforces its usefulness.
241-244: Comprehensive Overview for MultiUpsertObject EndpointThe revised documentation for
/upsert/object/multiplenow gives clear guidelines on updating multiple objects along with a warning on message size. The changes are well structured and complete.apis/swagger/v1/vald/flush.swagger.json (1)
15-18: Enhanced Flush Endpoint DescriptionThe updated summary for the
/flushendpoint now includes a detailed table of status codes and a descriptive overview that clearly explains the RPC purpose (removing all vectors). This added detail will help clients understand the operational context better.go.mod (3)
3-3: Update Go Version.
The Go version has been bumped from 1.24.0 to 1.24.2, ensuring consistency with the rest of the repository and any updated dependencies.
5-349: Comprehensive Dependency Updates in the Replace Block.
The replace section now specifies updated versions for many external modules (e.g., cloud.google.com/go, Azure SDK modules, and others). These updates look well‐organized. Please verify that all these version bumps are backward‑compatible and that no conflicts or regressions occur at runtime.
[suggest_assistance]
351-540: Extensive Dependency Updates in the Require Blocks.
Both direct and indirect dependencies have been thoroughly updated. Although these changes likely enhance security and compatibility, a careful test run is recommended to ensure that the updated versions do not affect the expected behavior of critical components.
[suggest_assistance]example/client/go.mod.default (1)
3-3: Update Go Version in Client Module.
The Go version in this client module has been updated from 1.24.0 to 1.24.2, aligning it with the main module. This change ensures consistency across the project..github/workflows/test-hack.yaml (1)
58-60: Add Container Credentials for Test-Hack Workflow.
A new credentials section has been added to the container configuration using secrets (PACKAGE_USER and PACKAGE_TOKEN). This change improves authentication for pulling the container image and overall security. Please ensure that these secrets are correctly set in the repository’s settings..github/workflows/build-binaries.yaml (1)
34-36: Add Container Credentials for Build-Binaries Workflow.
The container configuration now includes a credentials block with the appropriate secrets. This enhancement standardizes authentication across workflows and helps secure image pulls during the build process..github/workflows/e2e-profiling.yaml (1)
45-47: Add Container Credentials for E2E Profiling Workflow.
The credentials section has been added under the container configuration to allow authenticated access using the PACKAGE_USER and PACKAGE_TOKEN secrets. This aligns with the security improvements seen in other workflows..github/workflows/unit-test-rust.yaml (1)
44-46: Secure Container Credential Addition.
The addition of the container credentials (username and password) using GitHub secrets is a positive move to ensure authenticated access when pulling the CI container image. Please confirm that these secrets are properly managed and rotated..github/workflows/e2e-max-dim.yaml (1)
43-45: Container Credentials for E2E Test Job.
The newly added credentials ensure that the container used in the E2E max dimension insert job authenticates securely. This change is consistent with our overall approach for secure container pulls..github/workflows/build-protobuf.yaml (1)
43-45: Enhancing Build Security with Container Credentials.
Introducing the credentials under the container configuration for the build job adds a layer of security to the build process. Ensure that the secrets in use are kept current and have the appropriate access rights..github/workflows/_release-pr.yaml (1)
44-46: Release PR Workflow: Secure Container Authentication.
Adding the container credentials in this workflow enables authenticated access while creating release PRs. This improvement aligns well with our security guidelines; please verify that the secret values are correctly configured in GitHub..github/workflows/reviewdog.yaml (2)
35-37: GolangCI-Lint Job: Container Credentials Added.
The insertion of the container credentials in the golangci-lint job reinforces secure container access and maintains consistency across our workflows. No further changes are needed here.
57-59: Go Build Job: Container Credential Enhancement.
The new credentials block for the go-build job ensures that authentication for the container image is handled securely. This change follows our standard practice across CI workflows..github/workflows/unit-test.yaml (3)
54-56: Secure Container Credentials in thetest-cmdJob.
The introduction of thecredentialsblock withusernameandpassword(sourced from secrets) enhances the security for pulling the container image. Please verify that the secrets (PACKAGE_USERandPACKAGE_TOKEN) are correctly configured in the repository settings.
74-76: Secure Container Credentials in thetest-internalJob.
The added credential fields here mirror the secure setup intest-cmd, ensuring consistency across jobs. Confirm that these credentials are updated and maintained as per your security policies.
94-96: Secure Container Credentials in thetest-pkgJob.
The newcredentialsblock prevents unauthorized access by using repository secrets. Double-check that the secret values are current and securely stored..github/workflows/fossa.yaml (1)
39-41: Add Credentials for the FOSSA Scan Container.
This change integrates acredentialssection into the container configuration, ensuring that authentication is handled for the FOSSA scan process. Make sure the secrets (PACKAGE_USERandPACKAGE_TOKEN) are properly set for smooth execution..github/workflows/coverage.yaml (1)
45-47: Inject Credentials for the Coverage Job Container.
The credentials block added here secures the container image pull by providing authentication details. Please ensure thatPACKAGE_USERandPACKAGE_TOKENare updated in your secrets management..github/workflows/update-deps.yaml (1)
34-36: Secure Container Authentication in the Update Dependencies Workflow.
By adding thecredentialssection under the container configuration, this update secures the dependency update process. Verify that these credentials comply with your security and operational policies..github/ISSUE_TEMPLATE/bug_report.md (1)
25-32: Update Environment Versions in the Bug Report Template.
The version numbers for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss have been updated to reflect recent releases, ensuring that reported issues correlate with the current environment setup. Confirm that these version updates are aligned with your product requirements and dependency compatibility..github/workflows/helm.yaml (2)
38-40: Added container registry authentication.Good addition of container credentials for accessing the container registry. This enhances security by using GitHub secrets for authentication.
83-85: Added container registry authentication.Consistent application of container registry credentials for the remote Helm chart testing job. This follows the same pattern as the previous job in the workflow.
internal/net/grpc/status/status.go (1)
48-50: New utility function for error status code comparison.This
Isfunction is a useful addition that simplifies error status code checking in gRPC handlers. The implementation is concise and follows similar patterns to the standarderrors.Isfunction.Let's verify the usage of this function across the codebase:
#!/bin/bash # Search for potential usage of the new Is function rg "status\.Is\(" --type go.github/ISSUE_TEMPLATE/security_issue_report.md (1)
20-26: Updated software version references.The template has been updated with the latest software versions for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss. This ensures users report security issues with current version information.
.github/workflows/e2e-chaos.yaml (4)
47-49: Added container registry authentication.Good addition of container credentials for accessing the container registry in the agent-failure test job.
91-93: Added container registry authentication.Consistent application of container registry credentials for the random-pod-failure test job.
135-137: Added container registry authentication.Consistent application of container registry credentials for the agent-network-partition test job.
179-181: Added container registry authentication.Consistent application of container registry credentials for the clusterwide-network-bandwidth test job, completing the authentication enhancements across all test jobs in this workflow.
.github/PULL_REQUEST_TEMPLATE.md (1)
18-25: Version Update VerificationThe version numbers have been updated consistently (e.g., Go v1.24.1, Rust v1.85.1, Docker v28.0.4, Kubernetes v1.32.3, Helm v3.17.2, NGT v2.3.14, Faiss v1.10.0). Please ensure that these version changes are also reflected in the related documentation and, if applicable, the Helm charts mentioned in this PR.
.github/workflows/reviewdog-k8s.yaml (3)
36-38: Credentials Addition for kubeval-conflintThe new
credentialssection is properly added to the container configuration for the kubeval-conflint job. This reinforces secure access to the container image. Make sure that the secrets (PACKAGE_USERandPACKAGE_TOKEN) are correctly configured in your repository settings.
59-61: Credential Setup for kubelinter-k8s-manifestsThe addition of the credentials in the container definition for the kubelinter-k8s-manifests job is well implemented. This change is consistent with the overall security improvements.
81-83: Secure Credentials for kubelinter-vald-chartThe credentials section for the kubelinter-vald-chart job has been correctly inserted. Ensure that these secrets remain up to date and aligned with any similar configurations in other workflow files.
.github/workflows/e2e.yaml (8)
45-47: Credentials for e2e-stream-crud JobThe addition of the credentials in the container configuration for the e2e-stream-crud job is correctly implemented. This secures the image pull by using the GitHub secrets.
88-92: Secure Credentials for e2e-stream-crud-for-operatorThe credentials have been added in the container block for the e2e-stream-crud-for-operator job. This change is aligned with the new security practices and is implemented consistently.
156-159: Credentials in e2e-stream-crud-under-index-management-jobsThe credentials are now provided to the container image configuration, ensuring secure access. This addition is consistent with the updates from other sections.
203-207: Credentials for e2e-stream-crud-skip-exist-checkThe container configuration now includes credentials for the e2e-stream-crud-skip-exist-check job. It’s a good practice to maintain such security measures across all workflows.
247-251: Credential Update for e2e-multiapis-crudThe secure credentials have been added to the container block for the e2e-multiapis-crud job. This ensures consistent security standards when accessing private images.
287-291: Secure Credentials in e2e-jobsThe e2e-jobs configuration now correctly includes the credentials, which reinforces secure access to the container image.
325-327: Credentials for e2e-stream-crud-with-readreplicaThe addition of credentials to the container configuration for the e2e-stream-crud-with-readreplica job is correctly implemented. Please ensure that these secrets are actively maintained.
379-382: Credential Addition for e2e-stream-crud-with-mirrorThe credentials for the e2e-stream-crud-with-mirror job have been added in a manner consistent with the rest of the workflows. This enhances the security of the container pull process.
.github/workflows/helm-lint.yaml (3)
35-37: Credentials for lint-vald-chartAdding the credentials in the container configuration for the lint-vald-chart job is correctly done. This ensures that private container images are accessed securely during linting.
55-58: Credential Configuration for lint-vald-helm-operator-chartThe lint-vald-helm-operator-chart job now securely utilizes credentials. The consistency across workflows in this approach is commendable.
77-79: Secure Credentials for lint-values-schemaThe integration of credentials for the lint-values-schema job is appropriately implemented. This is in line with the enhanced security measures applied project-wide.
.github/workflows/e2e-code-bench-agent.yaml (2)
61-63: Credentials in grpc-sequential JobThe credentials for the grpc-sequential job have been added correctly to the container configuration. This ensures authenticated access to the container registry.
91-93: Credential Setup for grpc-streamSimilarly, the grpc-stream container now includes the credentials, consistently applying the security improvements.
.github/workflows/chatops.yaml (5)
32-34: Added container credentials configuration - good security practiceThe addition of credentials for accessing container images is a good security practice. This ensures proper authentication when the workflow needs to pull container images from private registries.
85-87: Consistent credentials handling across jobsThe credentials configuration has been consistently applied across all jobs in the workflow, maintaining a unified approach to authentication.
165-167: Proper credential management for CI tasksAdding credentials configuration to the container spec ensures the CI tasks can properly access container images, reducing potential authentication failures during automated processes.
281-283: Secure container registry authenticationThis credential configuration enhances security by using GitHub secrets to manage authentication credentials rather than hardcoding them.
416-418: Consistent authentication pattern across workflow filesThis credential configuration follows the same pattern implemented in other workflow files, showing a cohesive approach to container registry authentication throughout the CI/CD pipeline.
internal/client/v1/client/discoverer/discover.go (1)
290-290: Improved error handling with more concise APIThe refactoring from likely multiple
errors.Ischecks to a singleerrors.IsNotfunction call improves code readability while maintaining the same functionality. This is a good example of the error handling improvements mentioned in the PR objectives.This change aligns with the PR's objective to improve error handling in the
internal/errorspackage..github/workflows/_docker-image.yaml (1)
73-83: Added explicit Docker registry authentication stepsThe addition of dedicated steps for logging into DockerHub and GitHub Container Registry using the official
docker/login-actionis a good improvement. This ensures reliable authentication before building and pushing images.These steps use GitHub secrets appropriately for credential management, which is a security best practice.
.github/workflows/format.yaml (3)
36-38: Added container credentials for format jobAdding credentials for container registry access is consistent with the changes in other workflow files and follows best practices for authentication.
95-97: Consistent credential handling for check-format-diff jobThe credential configuration maintains consistency with other jobs and workflow files, ensuring proper authentication throughout the CI pipeline.
108-109: Enhanced formatting process with additional targetsThe format command has been expanded to include license checks and Go-specific formatting tasks, which improves code consistency. The additional checkout of
./rust/rust-toolchain.tomlappropriately handles the multi-language aspects of the codebase.This change aligns with the PR's objective to enhance maintainability by ensuring consistent formatting across the codebase.
internal/net/grpc/client.go (5)
173-178: Error handling refactoring looks goodThe replacement of multiple individual error checks with the new
errors.IsNotfunction improves code readability and maintainability by consolidating error handling logic.
261-269: Consistent error handling in connection pool rebalancingGood use of the same error handling pattern in the connection pool rebalancing logic, which maintains consistency with other parts of the codebase.
299-307: Clean error handling in health check logicThe error handling in the health check logic follows the same improved pattern, making the code more maintainable.
374-382: Improved error handling in disconnect logicThe consistent use of
errors.IsNothelps streamline error handling in the disconnect logic section.
480-482: Consistent error handling pattern throughout the fileThe consistent application of the new error handling pattern across the entire file demonstrates good attention to code quality and maintainability.
Also applies to: 753-758, 762-764, 853-864, 888-894, 983-984, 994-995, 1090-1092
internal/client/v1/client/discoverer/discover_test.go (1)
1242-1242: LGTM: Removed unused error channel parameter from test functions.The removal of the unused error channel parameter (which was previously passed as
nil) from these test functions is a good cleanup that simplifies the function signatures without changing functionality.Also applies to: 1408-1408, 1578-1578, 1921-1921, 2093-2093
.github/workflows/codeql-analysis.yml (4)
46-57: Excellent improvement to CodeQL workflow with matrix-based analysis.The introduction of a matrix strategy for analyzing different languages separately is a significant improvement. Each language will have its dedicated analysis with appropriate runner selection and configuration.
58-67: Well-structured matrix configuration for multi-language analysis.The matrix configuration properly defines the build modes for each language, ensuring appropriate analysis for each language type.
70-72: Properly configured container credentials.Adding proper credentials configuration for the container is important for secure access to the container registry.
84-88: Updated to latest CodeQL action versions with appropriate configuration.The upgrade to v3 of all CodeQL actions and the dynamic configuration based on the matrix strategy improves the analysis capabilities. The conditional autobuild for Go and the language-specific categorization will make results more manageable.
Also applies to: 90-91, 93-95
hack/go.mod.default (3)
3-3: Updated Go version to latest patch release.Updating to Go 1.24.2 brings in the latest bug fixes and security improvements.
16-16: Using flexible 'upgrade' directive for dependencies.Changing from pinned versions to the 'upgrade' directive for cloud storage and JSON libraries will allow using the latest compatible versions automatically.
Also applies to: 134-134
332-337:❓ Verification inconclusive
Updated Kubernetes dependencies and controller runtime.
The update to controller-runtime from v0.19.3 to v0.20.4 is a minor version upgrade that might include behavior changes.
Please verify compatibility with the upgraded controller-runtime by checking the release notes for any breaking changes:
Also applies to: 340-341, 344-344, 347-347
🌐 Web query:
What are the breaking changes in controller-runtime v0.20.0 compared to v0.19.3?💡 Result:
controller-runtime v0.20.0 introduced several breaking changes compared to v0.19.x versions, primarily due to Kubernetes client library updates and deprecated feature removals. Here are the key breaking changes:
Kubernetes Library Upgrades
- Switch to k8s.io/client-go v1.32: Projects must now use Kubernetes v1.32 client libraries, requiring dependency updates and potential code adjustments for API changes[1][4].
Webhook Changes
- CustomDefaulter behavior: Webhooks no longer automatically delete unknown fields during defaulting, requiring explicit handling of unknown fields in custom admission logic[1][4].
- Removed deprecated interfaces: The legacy
admission.Decoderandadmission.Handlerinterfaces were removed, forcing migration to newer webhook patterns[1][4].Logging Modifications
- API warning deduplication disabled: Applications might see duplicate API warnings in logs unless explicitly configured to deduplicate[1][4].
Manager Configuration
- SyncPeriod removal: The deprecated
cluster.SyncPeriodoption was removed, requiring users to configure synchronization through manager options instead[1][4].Leader Election
- Mandatory manager configuration: Leader election timeouts now require explicit configuration rather than relying on defaults[1][4].
These changes require careful migration planning for controllers using older patterns. The upgrade also brings Kubernetes 1.32 compatibility and new features like experimental priority queues, but these require explicit opt-in during controller configuration[1][4].
Citations:
- 1: https://github.com/kubernetes-sigs/controller-runtime/releases
- 2: https://sdk.operatorframework.io/docs/building-operators/golang/references/client/
- 3: https://karpenter.sh/docs/upgrading/upgrade-guide/
- 4: https://newreleases.io/project/github/kubernetes-sigs/controller-runtime/release/v0.20.0
- 5: https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/builder
- 6: https://karpenter.sh/v0.32/upgrading/upgrade-guide/
- 7: https://pkg.go.dev/sigs.k8s.io/controller-runtime
- 8: https://cloud.google.com/kubernetes-engine/enterprise/config-sync/docs/release-notes
- 9: https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-platform-for-cloud-foundry/4-0/tpcf/runtime-rn-patches2.html
- 10: https://sdk.operatorframework.io/docs/upgrading-sdk-version/version-upgrade-guide/
ACTION: Verify Compatibility with Controller-runtime v0.20.4
File:
hack/go.mod.default(lines 332–337; also applies to lines 340–341, 344, 347)The Kubernetes dependencies have been updated to v0.32.3, and the controller-runtime upgrade from v0.19.3 to v0.20.4 brings several breaking changes that may impact our codebase. Key points to verify:
- Kubernetes Client Upgrade: Controller-runtime v0.20.x now depends on
k8s.io/client-go v1.32, so ensure all related client usage is compliant.- Webhook Adjustments: Changes in webhook behavior mean that custom defaulter logic might need to explicitly handle unknown fields. Additionally, deprecated interfaces like
admission.Decoderandadmission.Handlerhave been removed.- Logging Changes: Expect that API warning deduplication is disabled, which could result in duplicate warnings unless managed properly.
- Manager and Leader Election: The deprecated
cluster.SyncPeriodoption has been removed, and leader election timeouts now require explicit configuration.Please review the controller-runtime release notes and ensure that our controllers, webhooks, and manager configurations have been adjusted accordingly.
example/client/go.mod (2)
3-3: Updated Go version and dependencies to latest versions.Keeping dependencies up-to-date with the latest security patches and bug fixes is good practice.
Also applies to: 10-18, 36-41
17-17: Potential inconsistency in gRPC versions.There's a minor inconsistency in the gRPC version: line 17 specifies v1.71.1 in the replace section, while line 28 requires v1.71.0.
Consider aligning these versions to avoid potential confusion:
-google.golang.org/grpc => google.golang.org/grpc v1.71.1 +google.golang.org/grpc => google.golang.org/grpc v1.71.0or
-google.golang.org/grpc v1.71.0 +google.golang.org/grpc v1.71.1Also applies to: 28-28
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (3)
internal/db/nosql/cassandra/option_test.go (1)
17-18:⚠️ Potential issueFix incorrect package comment.
The package comment incorrectly states "Package redis provides implementation of Go API for redis interface" but the package is actually "cassandra".
-// Package redis provides implementation of Go API for redis interface +// Package cassandra provides implementation of Go API for cassandra interface package cassandrainternal/net/grpc/option_test.go (1)
532-615:⚠️ Potential issuePotential duplicate test function: TestWithMaxRecvMsgSize appears twice.
The file has two test functions named
TestWithMaxRecvMsgSize, one at lines 532-615 (renamed fromTestWithDialOptions) and another at lines 1382-1465. Having duplicate test function names will cause compilation errors.#!/bin/bash # Verify if there are duplicate test function declarations in the file grep -n "func TestWithMaxRecvMsgSize" internal/net/grpc/option_test.goAlso applies to: 1382-1465
go.mod (1)
6-357: 🛠️ Refactor suggestionDependency updates.
A large set of dependencies were upgraded (e.g., variouscloud.google.com/go,github.com/aws/aws-sdk-go-v2, etc.). This can introduce changes in transitive APIs, bug fixes, or deprecations. Consider running a full build and test with these versions to ensure backward compatibility.
🧹 Nitpick comments (43)
dockers/ci/base/Dockerfile (1)
130-130: Non-Functional Formatting ChangeThe
ENTRYPOINT ["/bin/bash"]instruction remains entirely unchanged in its execution, with only a formatting alteration (likely the removal of an extra newline at the end of the file). This appears to be a standardization alignment with other Dockerfiles in the repository.internal/info/info_test.go (1)
996-1094: New test function for ShortString method added.A new test function
TestStackTrace_ShortStringhas been added to test theShortString()method of theStackTracestruct. The function follows the same template structure as other tests in the file, which is good for consistency.However, the test cases are currently marked as TODO and not implemented yet. Consider adding actual test cases to validate the functionality of the
ShortString()method.Since this is part of an E2E test framework enhancement, having comprehensive test coverage is important. Consider implementing at least one basic test case that validates the expected output format of the
ShortString()method.apis/swagger/v1/vald/object.swagger.json (2)
47-47: Placeholders in/object/listEndpointThe summary for the
/object/listendpoint still contains "TODO" placeholders for the Status Code and Troubleshooting sections. Please update these fields with actual details or remove the placeholders to avoid confusion.
77-77: Incomplete Information in/object/meta/{id.id}EndpointSimilar to the previous endpoint, the summary for
/object/meta/{id.id}includes "TODO" placeholders in the Status Code and Troubleshooting sections. Filling in these fields or removing the placeholders will improve clarity for users.internal/config/benchmark_test.go (1)
16-112: Consider fully implementing the TestBenchmarkTarget_Bind test.The file contains commented test code marked as "NOT IMPLEMENTED BELOW". Since you're updating the structure to include the new
Metafield, this could be a good opportunity to implement the actual test to verify theBind()method works correctly with metadata.apis/swagger/v1/vald/index.swagger.json (2)
17-17: Grammar in Index Detail Summary
The new summary for the/index/detailendpoint reads:
"summary": "Overview\nRepresent the RPC to get the index information for each agents."
Consider revising “for each agents” to “for each agent” (or “for all agents”) for correct grammar.
101-101: Grammar in Statistics Detail Summary
The summary for/index/statistics/detailsays:
"summary": "Overview\nRepresent the RPC to get the index statistics for each agents."
Like the other endpoint, consider revising “for each agents” to “for each agent” for grammatical consistency.apis/swagger/v1/vald/insert.swagger.json (1)
17-17: Typo in Insert Summary
In the/insertendpoint the summary introduces the RPC as “Inset RPC”. This appears to be a typo. Consider changing “Inset RPC” to “Insert RPC” to correct the error.apis/swagger/v1/vald/update.swagger.json (1)
83-83: Incomplete Documentation for Update Timestamp
The/update/timestampendpoint summary currently contains placeholder “TODO” entries for both status codes and troubleshooting sections. Please update these fields with proper details or, if intended as a placeholder, add a comment to indicate that the documentation will be completed soon.apis/swagger/v1/vald/filter.swagger.json (2)
177-178: Enriched Summary and Description for/update/object/multipleEndpoint.
The updated documentation provides a concise summary and a supplementary description that outlines the gRPC message size limitation along with related status codes.
It is recommended to adjust the phrase “the size of the request exceed the limit” to “the size of the request exceeds the limit” for grammatical consistency.
242-244: Enhanced Summary and Description for/upsert/object/multipleEndpoint.
The updated documentation delivers a comprehensive overview that includes notices on gRPC message size limitations and a detailed status code table.
A minor suggestion is to verify consistency in punctuation and formatting across endpoints for a uniform documentation style.apis/docs/v1/docs.md (4)
1372-1377: Mirror Service Overview Update
The new overview clearly states that the Mirror service provides theRegisterinterface for the Vald Mirror Gateway. However, the table header on line 1375 appears to contain extra column delimiters which could affect readability. Consider revising the markdown table formatting for clarity.
1636-1639: Filter Service Overview Update
The updated "Overview" for the Filter service is concise. One nitpick: the statement "Vald Filter Gateway forward user request to user-defined ingress/egress filter components" should be revised for grammatical correctness (e.g. "forwards user requests" or "forwards the user request").
1747-1749: Object Service Overview Update
The overview explains that the Object Service handles retrieving inserted vectors and verifying their insertion. For improved clarity, consider rephrasing "checking whether vectors are inserted" to "verifying if vectors have been successfully inserted."
1906-1908: Update Service Overview Update
The overview for the Update Service is present; however, the phrasing "updates to new vector from inserted vector" is a bit awkward. Consider rephrasing to something like "updates an existing vector with new values" to enhance clarity.internal/core/algorithm/usearch/usearch_test.go (2)
219-261: Consider uncommenting this test case if it's reliableThis test case for verifying the most accurate search results is commented out. If this was intentionally disabled due to flakiness or other issues, consider adding a comment explaining why it's disabled or fix the underlying issues to enable it.
-// { -// name: "return most accurate result after insert 10 vectors with limited size 5", -// args: args{ -// q: []float32{1, 2, 3, 4, 5, 6, 7, 8, 9}, -// k: 5, -// }, -// fields: fields{ -// idxPath: idxTempDir(t), -// quantizationType: "F32", -// metricType: "cosine", -// dimension: 9, -// connectivity: 0, -// expansionAdd: 0, -// expansionSearch: 0, -// multi: false, -// }, -// createFunc: func(t *testing.T, fields fields) (Usearch, error) { -// t.Helper() -// ivs := [][]float32{ -// {0, 1, 2, 3, 4, 5, 6, 7, 8}, // vec id 1 -// {2, 3, 4, 5, 6, 7, 8, 9, 10}, // vec id 2 -// {0, 1, 2, 3, 4, 5, 6, 7, 8}, // vec id 3 -// {2, 3, 4, 5, 6, 7, 8, 9, 10}, // vec id 4 -// {0, 1, 2, 3, 4, 5, 6, 7, 8}, // vec id 5 -// {2, 3, 4, 5, 6, 7, 8, 9, 10}, // vec id 6 -// {2, 3, 4, 5, 6, 7, 8, 9, 9.04}, // vec id 7 -// {2, 3, 4, 5, 6, 7, 8, 9, 9.03}, // vec id 8 -// {1, 2, 3, 4, 5, 6, 7, 8, 9.01}, // vec id 9 -// {1, 2, 3, 4, 5, 6, 7, 8, 9.02}, // vec id 10 -// } - -// return insertCreateFunc(t, fields, ivs, 10) -// }, -// want: want{ -// want: []algorithm.SearchResult{ -// {ID: uint32(10), Distance: 2.384185791015625e-07}, -// {ID: uint32(9), Distance: 5.364418029785156e-07}, -// {ID: uint32(6), Distance: 3}, -// {ID: uint32(4), Distance: 3}, -// {ID: uint32(2), Distance: 3}, -// }, -// }, -// }, +{ + name: "return most accurate result after insert 10 vectors with limited size 5", + args: args{ + q: []float32{1, 2, 3, 4, 5, 6, 7, 8, 9}, + k: 5, + }, + fields: fields{ + idxPath: idxTempDir(t), + quantizationType: "F32", + metricType: "cosine", + dimension: 9, + connectivity: 0, + expansionAdd: 0, + expansionSearch: 0, + multi: false, + }, + createFunc: func(t *testing.T, fields fields) (Usearch, error) { + t.Helper() + ivs := [][]float32{ + {0, 1, 2, 3, 4, 5, 6, 7, 8}, // vec id 1 + {2, 3, 4, 5, 6, 7, 8, 9, 10}, // vec id 2 + {0, 1, 2, 3, 4, 5, 6, 7, 8}, // vec id 3 + {2, 3, 4, 5, 6, 7, 8, 9, 10}, // vec id 4 + {0, 1, 2, 3, 4, 5, 6, 7, 8}, // vec id 5 + {2, 3, 4, 5, 6, 7, 8, 9, 10}, // vec id 6 + {2, 3, 4, 5, 6, 7, 8, 9, 9.04}, // vec id 7 + {2, 3, 4, 5, 6, 7, 8, 9, 9.03}, // vec id 8 + {1, 2, 3, 4, 5, 6, 7, 8, 9.01}, // vec id 9 + {1, 2, 3, 4, 5, 6, 7, 8, 9.02}, // vec id 10 + } + + return insertCreateFunc(t, fields, ivs, 10) + }, + want: want{ + want: []algorithm.SearchResult{ + {ID: uint32(10), Distance: 2.384185791015625e-07}, + {ID: uint32(9), Distance: 5.364418029785156e-07}, + {ID: uint32(6), Distance: 3}, + {ID: uint32(4), Distance: 3}, + {ID: uint32(2), Distance: 3}, + }, + }, +},If the test was disabled due to reliability issues, consider adding a comment explaining the reason:
// Disabled due to flakiness with floating point precision comparisons // { // name: "return most accurate result after insert 10 vectors with limited size 5", // ...
353-1679: Implement TODO test cases to increase test coverageThere are numerous commented-out test cases labeled as "NOT IMPLEMENTED" or "TODO test cases". Implementing these tests would significantly improve test coverage for the USearch implementation.
Would you like me to help generate implementation examples for some of these test cases? I can provide a pattern for implementing one of these tests that you can follow for the others.
internal/errors/params.go (1)
1-21: New Error Declaration and Documentation RecommendationThe new error variable
ErrArgumentParserNotFoundis clearly declared using the customNewfunction. For improved maintainability and autogenerated documentation, consider adding a descriptive doc comment above the declaration explaining the context and when this error should be used.charts/vald/values/dev.yaml (1)
49-49: New Configuration Option AddedThe addition of the
enable_statistics: trueoption under thengtsection effectively enables statistics collection for the NGT component. Please ensure that any related documentation or usage notes are updated accordingly, so users are aware of this new parameter.internal/net/grpc/pool/pool_bench_test.go (1)
120-120: Benchmark loop construct updatedChanged from using manual iteration to
b.Loop(), which is a more idiomatic way to handle benchmarking in Go. This approach lets the testing framework control the iteration instead of manually counting tob.N.For consistency, consider updating the benchmark loop in the parallel benchmark methods on lines 176 and 202 to use the same pattern if applicable.
Also applies to: 144-144
internal/net/dialer_test.go (1)
1992-2079: Added placeholder for QUIC dial test - consider implementation timelineThis code adds a commented-out test function
Test_isQUICDialthat's intended to test QUIC connection detection functionality. The test structure follows the established pattern in the file with proper argument types, validation, and test cases.Since this is currently just a placeholder with TODO comments, consider:
- Adding a comment with expected implementation timeline
- Creating a tracking issue for implementing the actual test
- Implementing at least one basic test case if the
isQUICDialfunction already existsYou could add a simple test case implementation like:
// tests := []test{ // // TODO test cases +// { +// name: "returns true for QUIC network", +// args: args { +// network: "quic", +// addr: "example.com:443", +// }, +// want: want{ +// want: true, +// }, +// }, +// { +// name: "returns false for TCP network", +// args: args { +// network: "tcp", +// addr: "example.com:443", +// }, +// want: want{ +// want: false, +// }, +// },internal/config/index_deleter_test.go (1)
18-140:❓ Verification inconclusive
Test template for
IndexDeleter.Bindrequires implementationThis file contains a commented-out test template for the
IndexDeleter.Bindmethod without any actual test cases. To ensure proper test coverage, this test should be implemented with appropriate test cases.I can help you implement test cases for this function. Would you like me to generate some test cases based on the IndexDeleter's functionality?
🏁 Script executed:
#!/bin/bash # Look for the IndexDeleter.Bind implementation to understand what should be tested rg -A 5 "func \(\*IndexDeleter\) Bind\(" --type go internal/config/Length of output: 69
Action: Verify and Implement Test Cases for IndexDeleter.Bind
The current test file (
internal/config/index_deleter_test.go, lines 18–140) contains only commented-out test templates for theIndexDeleter.Bindmethod and does not include any concrete test cases. Additionally, our automated search did not yield any output for theBindmethod implementation in the expected location, which raises uncertainty about whether the method is implemented or if it exists elsewhere.Please verify the following:
- Confirm that the
IndexDeleter.Bindmethod exists and is implemented as expected.- If the method is implemented, update this test file with concrete test cases that reflect its intended functionality.
- If the method is not yet implemented or has been moved, consider updating or removing the test template accordingly.
internal/client/v1/client/discoverer/discover_test.go (4)
1242-1242: Consider removing or uncommenting the code.This line is commented out, so no test coverage is provided for
dnsDiscovery. If it's obsolete, consider deleting it to reduce clutter. If it is intended for future use, add a TODO comment to clarify its purpose.
1408-1408: Consider removing or uncommenting the code.Likewise, this commented-out call to
discoveroffers no test coverage. If you plan to restore it for upcoming tests, leave a clear note; otherwise, consider removing it to maintain a clean test suite.
1921-1921: Ensure test coverage or remove commented-out call.The line referencing
c.discoverAddrsis similarly commented out. If these tests are not needed, remove them; otherwise, uncomment and implement them to confirm functionality.
2093-2093: Unused test invocation fordisconnectOldAddrs.If testing
disconnectOldAddrsis part of your plan, uncomment and complete the test. Otherwise, remove this line to keep tests focused and maintainable.internal/iter/iter.go (2)
22-23: Potential naming collision with the importediterpackage.Importing
"iter"while the current package's name is alsoitercan cause confusion or ambiguous references. Consider renaming the import alias or the package to avoid confusion and potential cyclical imports.
70-78: Incremental transformation withAt.Applying
modFunc(i, c.array[idx])on-the-fly is efficient and flexible. If performance becomes critical, you might optimize repeated% c.sizecalls inside tight loops, but keep it as-is unless profiling indicates a bottleneck.internal/errors/k8s.go (1)
20-46: Added new Kubernetes error definitions for enhanced error handling.This change introduces a comprehensive set of error variables related to Kubernetes operations, which will likely improve error handling and debugging in the new E2E testing framework. These well-defined error types make the codebase more maintainable.
One minor inconsistency to note:
ErrUndefinedNamespaceandErrUndefinedServicestart with a capitalized "Undefined", while other error messages follow lowercase style. Consider standardizing the error message casing for consistency.-ErrUndefinedNamespace = New("Undefined namespace") +ErrUndefinedNamespace = New("undefined namespace") -ErrUndefinedService = New("Undefined service") +ErrUndefinedService = New("undefined service").github/workflows/build-protobuf.yaml (1)
43-45: Added container registry authenticationContainer registry credentials have been added to the GitHub workflow, improving security by authenticating with the registry using secrets.
Consider applying this pattern to all your GitHub workflows consistently to enhance security across your CI/CD pipeline.
Makefile.d/functions.mk (1)
134-154: Well-structured implementation of new V2 E2E test functionThe new
run-v2-e2e-crud-testfunction is well-structured and supports the PR's objective of introducing a new E2E testing framework with improved maintainability. It takes a more configuration-based approach compared to the original version.Consider adding a comment before the function to document its purpose and usage, similar to the comments present for other functions in this file (e.g., lines 297-301).
+# This function runs V2 E2E CRUD tests with configuration file approach +# It uses environment variables for test parameters and targets the new V2 testing framework define run-v2-e2e-crud-test GOPRIVATE=$(GOPRIVATE) \ GOARCH=$(GOARCH) \.github/workflows/e2e.yaml (1)
45-47: Security enhancement: Added container registry authentication.Adding credentials to container configurations is a good security practice. This ensures proper authentication when pulling container images from GitHub Container Registry, which is especially important for private repositories or when rate limits apply.
Consider using a GitHub Actions composite action or reusable workflow to avoid duplicating the credential configuration across multiple jobs.
Also applies to: 89-91, 156-158, 204-206, 248-250, 288-290, 325-327, 379-381
cmd/index/job/deletion/main_test.go (1)
1-87: Test framework for index deletion job.This commented-out test structure provides a good template for testing the main function when ready to implement. It follows the project's test pattern with appropriate setup/teardown functions and parallel test execution.
Would you like help implementing these tests to improve coverage for the index deletion job? The basic structure is in place, but needs actual test cases and validation logic.
internal/net/grpc/metadata_test.go (1)
18-101: Test skeleton added for NewMetadata function.A comprehensive test structure has been added for the
NewMetadatafunction, including setup for arguments, expectations, and test case organization. However, since the test is commented out and no actual test cases are implemented, this serves as a good skeleton for future test implementation.Consider implementing actual test cases to complete this skeleton or removing the commented code if it's not intended for immediate use.
If you plan to implement this test soon, you could uncomment it and add at least one basic test case like:
{ name: "test_with_empty_map", args: args{ m: map[string]string{}, }, want: want{ want: MD{}, }, checkFunc: defaultCheckFunc, }, { name: "test_with_single_key_value_pair", args: args{ m: map[string]string{"key": "value"}, }, want: want{ want: NewMetadata(map[string]string{"key": "value"}), }, checkFunc: defaultCheckFunc, }internal/net/grpc/option_test.go (1)
532-1720: Suggest implementing the actual test logic.While the test function signatures have been updated, most of the actual test implementations remain commented out. Consider implementing these tests to verify the behavior of the option functions.
For example, implement actual test cases for
TestWithBackoffMaxDelayby replacing the TODO with real test cases that verify the function behaves as expected with different duration strings:- // TODO test cases + { + name: "valid_duration", + args: args { + dur:"10s", + }, + want: want{ + // Expected option value + }, + checkFunc: defaultCheckFunc, + }, + { + name: "invalid_duration", + args: args { + dur:"invalid", + }, + want: want{ + // Expected option value or error handling + }, + checkFunc: defaultCheckFunc, + },internal/net/grpc/pool/pool.go (8)
17-20: Consider rephrasing or condensing the package documentation.
The introductory block comment reads well, but it might be a bit verbose. Consider succinctly describing the purpose and highlighting key new features of this lock-free pool.
49-71: Evaluate interface scope.
TheConninterface has grown to include many methods (IsIPConn,IsHealthy,Reconnect, etc.). While comprehensive, large interfaces can sometimes reduce testability and clarity. Consider splitting or grouping related capabilities into smaller interfaces if appropriate.
267-273: getSlots() usage.
Returning*[]atomic.Pointer[poolConn]is somewhat unusual. Consider whether a slice reference is necessary or if a direct slice copy might suffice. This can reduce accidental pointer manipulation outside the intended scope.
342-385: refreshConn() complexities.
This function attempts to dial a new connection if the existing one is unhealthy. Key points:
- The fallback logic uses
isHealthy(). Ensure it is robust for partial states.- The old connection closure is spawned via
errGroup.Go(...). This is good for concurrency.
584-595: Do() with lazy retry.
CallinggetHealthyConn()and then letting the user’s callback handle the connection is straightforward. Consider carefully whether to retry the user’s function on transient failures, or if that is the caller’s responsibility.
606-633: IsHealthy() logic.
- For IP-based pools, all slots must be healthy. For DNS-based, only some need to be healthy.
- This design choice is interesting but presumably intended: IP-based clusters typically require each IP to be accessible.
661-696: lookupIPAddr(): DNS resolution + quick TCP check.
- The short 10ms dial for each IP is a nice lightweight “ping.”
- Potential edge case: slower networks or large DNS responses.
698-723: scanGRPCPort() for dynamic port detection.
Tries each port in the scanned range and does a quick gRPC dial to confirm readiness. This is robust, though it could be slow for large port ranges.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (31)
apis/grpc/v1/agent/core/agent.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/agent/sidecar/sidecar.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/discoverer/discoverer.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/egress/egress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/ingress/ingress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/meta/meta.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/payload/payload.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/rpc/errdetails/error_details.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goexample/client/go.sumis excluded by!**/*.sumgo.sumis excluded by!**/*.sumrust/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (107)
.gitfiles(15 hunks).github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/security_issue_report.md(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks).github/workflows/_docker-image.yaml(1 hunks).github/workflows/_release-pr.yaml(1 hunks).github/workflows/build-binaries.yaml(1 hunks).github/workflows/build-protobuf.yaml(1 hunks).github/workflows/chatops.yaml(5 hunks).github/workflows/codeql-analysis.yml(2 hunks).github/workflows/coverage.yaml(1 hunks).github/workflows/e2e-chaos.yaml(4 hunks).github/workflows/e2e-code-bench-agent.yaml(2 hunks).github/workflows/e2e-max-dim.yaml(1 hunks).github/workflows/e2e-profiling.yaml(1 hunks).github/workflows/e2e.yaml(8 hunks).github/workflows/format.yaml(3 hunks).github/workflows/fossa.yaml(1 hunks).github/workflows/helm-lint.yaml(3 hunks).github/workflows/helm.yaml(2 hunks).github/workflows/reviewdog-k8s.yaml(3 hunks).github/workflows/reviewdog.yaml(2 hunks).github/workflows/test-hack.yaml(1 hunks).github/workflows/unit-test-rust.yaml(1 hunks).github/workflows/unit-test.yaml(3 hunks).github/workflows/update-deps.yaml(1 hunks)Makefile(8 hunks)Makefile.d/e2e.mk(1 hunks)Makefile.d/functions.mk(1 hunks)Makefile.d/minikube.mk(1 hunks)Makefile.d/tools.mk(2 hunks)apis/docs/v1/docs.md(10 hunks)apis/swagger/v1/mirror/mirror.swagger.json(1 hunks)apis/swagger/v1/vald/filter.swagger.json(8 hunks)apis/swagger/v1/vald/flush.swagger.json(1 hunks)apis/swagger/v1/vald/index.swagger.json(5 hunks)apis/swagger/v1/vald/insert.swagger.json(2 hunks)apis/swagger/v1/vald/object.swagger.json(4 hunks)apis/swagger/v1/vald/remove.swagger.json(3 hunks)apis/swagger/v1/vald/search.swagger.json(8 hunks)apis/swagger/v1/vald/update.swagger.json(3 hunks)apis/swagger/v1/vald/upsert.swagger.json(2 hunks)charts/vald/values/dev.yaml(1 hunks)cmd/index/job/deletion/main_test.go(1 hunks)dockers/agent/core/agent/Dockerfile(1 hunks)dockers/agent/core/faiss/Dockerfile(1 hunks)dockers/agent/core/ngt/Dockerfile(1 hunks)dockers/agent/sidecar/Dockerfile(1 hunks)dockers/binfmt/Dockerfile(1 hunks)dockers/buildbase/Dockerfile(1 hunks)dockers/buildkit/Dockerfile(1 hunks)dockers/buildkit/syft/scanner/Dockerfile(1 hunks)dockers/ci/base/Dockerfile(1 hunks)dockers/dev/Dockerfile(1 hunks)dockers/discoverer/k8s/Dockerfile(1 hunks)dockers/example/client/Dockerfile(1 hunks)dockers/gateway/filter/Dockerfile(1 hunks)dockers/gateway/lb/Dockerfile(1 hunks)dockers/gateway/mirror/Dockerfile(1 hunks)dockers/index/job/correction/Dockerfile(1 hunks)dockers/index/job/creation/Dockerfile(1 hunks)dockers/index/job/deletion/Dockerfile(1 hunks)dockers/index/job/readreplica/rotate/Dockerfile(1 hunks)dockers/index/job/save/Dockerfile(1 hunks)dockers/index/operator/Dockerfile(1 hunks)dockers/manager/index/Dockerfile(1 hunks)dockers/operator/helm/Dockerfile(1 hunks)dockers/tools/benchmark/job/Dockerfile(1 hunks)dockers/tools/benchmark/operator/Dockerfile(1 hunks)dockers/tools/cli/loadtest/Dockerfile(1 hunks)example/client/go.mod(2 hunks)example/client/go.mod.default(1 hunks)go.mod(14 hunks)hack/go.mod.default(4 hunks)internal/backoff/backoff.go(2 hunks)internal/backoff/backoff_test.go(1 hunks)internal/backoff/option.go(0 hunks)internal/backoff/option_test.go(0 hunks)internal/client/v1/client/discoverer/discover.go(1 hunks)internal/client/v1/client/discoverer/discover_test.go(5 hunks)internal/config/benchmark_test.go(4 hunks)internal/config/config.go(2 hunks)internal/config/config_test.go(1 hunks)internal/config/grpc.go(1 hunks)internal/config/index_deleter_test.go(1 hunks)internal/core/algorithm/usearch/usearch_test.go(16 hunks)internal/db/nosql/cassandra/option_test.go(8 hunks)internal/errors/errors.go(2 hunks)internal/errors/errors_test.go(1 hunks)internal/errors/k8s.go(1 hunks)internal/errors/params.go(1 hunks)internal/file/file.go(3 hunks)internal/file/file_test.go(1 hunks)internal/info/info_test.go(17 hunks)internal/iter/iter.go(1 hunks)internal/net/dialer_test.go(1 hunks)internal/net/grpc/client.go(13 hunks)internal/net/grpc/errdetails/errdetails.go(6 hunks)internal/net/grpc/metadata_test.go(1 hunks)internal/net/grpc/option.go(1 hunks)internal/net/grpc/option_test.go(46 hunks)internal/net/grpc/pool/option.go(1 hunks)internal/net/grpc/pool/option_test.go(6 hunks)internal/net/grpc/pool/pool.go(6 hunks)internal/net/grpc/pool/pool_bench_test.go(2 hunks)internal/net/grpc/server_test.go(2 hunks)internal/net/grpc/status/status.go(1 hunks)
⛔ Files not processed due to max files limit (46)
- internal/net/grpc/status/status_test.go
- internal/net/grpc/stream.go
- internal/net/grpc/stream_test.go
- internal/net/http/client/client.go
- internal/net/http/client/client_test.go
- internal/net/http/client/option_test.go
- internal/net/net.go
- internal/net/net_test.go
- internal/net/quic/conn_test.go
- internal/net/quic/listener_test.go
- internal/params/option.go
- internal/params/option_test.go
- internal/params/params.go
- internal/params/params_test.go
- internal/rand/rand.go
- internal/runner/runner.go
- internal/servers/server/option_test.go
- internal/servers/server/server.go
- internal/servers/servers.go
- internal/sync/errgroup/group.go
- internal/sync/errgroup/group_test.go
- internal/test/data/vector/gen.go
- internal/test/data/vector/noise/noise.go
- internal/test/data/vector/noise/noise_test.go
- internal/test/data/vector/noise/option.go
- internal/test/data/vector/noise/option_test.go
- internal/test/mock/server_stream.go
- internal/timeutil/time.go
- internal/timeutil/time_test.go
- k8s/agent/ngt/configmap.yaml
- k8s/discoverer/deployment.yaml
- k8s/gateway/gateway/lb/deployment.yaml
- k8s/gateway/gateway/mirror/deployment.yaml
- k8s/index/operator/deployment.yaml
- k8s/manager/index/deployment.yaml
- pkg/agent/core/faiss/service/faiss.go
- pkg/agent/core/ngt/service/ngt.go
- pkg/agent/core/ngt/service/ngt_test.go
- pkg/agent/core/ngt/service/option_test.go
- pkg/discoverer/k8s/service/discover_test.go
- pkg/gateway/lb/handler/grpc/aggregation_test.go
- pkg/gateway/lb/handler/grpc/handler_test.go
- pkg/gateway/mirror/service/mirror.go
- pkg/index/job/deletion/config/config_test.go
- pkg/index/job/deletion/service/deleter_test.go
- pkg/index/job/deletion/service/options_test.go
💤 Files with no reviewable changes (2)
- internal/backoff/option_test.go
- internal/backoff/option.go
🧰 Additional context used
🧠 Learnings (1)
.gitfiles (1)
Learnt from: datelier
PR: vdaas/vald#2807
File: rust/bin/agent/src/handler/object.rs:36-38
Timestamp: 2025-04-01T12:29:37.305Z
Learning: In Rust code for Vald handlers, avoid using unwrap() on Option types. Instead, handle None values explicitly by returning appropriate error statuses to maintain robustness.
🧬 Code Definitions (5)
internal/net/grpc/status/status.go (2)
internal/errors/errors.go (1)
Is(163-168)internal/net/grpc/codes/codes.go (1)
Code(22-22)
internal/config/grpc.go (1)
internal/net/grpc/option.go (1)
WithOldConnCloseDelay(656-663)
internal/net/grpc/client.go (3)
internal/errors/errors.go (3)
IsNot(182-192)IsAny(170-180)Is(163-168)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/net/grpc/status/status.go (3)
Error(125-127)FromError(185-257)Is(48-50)
internal/errors/errors.go (1)
internal/net/grpc/status/status.go (2)
Errorf(129-131)Is(48-50)
internal/net/grpc/pool/pool.go (5)
internal/net/grpc/client.go (3)
ClientConn(50-50)DialOption(49-49)New(129-154)internal/net/net.go (4)
Conn(41-41)Parse(188-222)SplitHostPort(242-264)DefaultResolver(88-88)internal/net/grpc/status/status.go (4)
Is(48-50)New(44-46)Errorf(129-131)Error(125-127)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/net/grpc/option.go (1)
Option(41-41)
🔇 Additional comments (224)
dockers/binfmt/Dockerfile (1)
20-21: Minor Formatting Improvement: Newline at End-of-File & Unchanged Base ImageThe diff introduces a newline at the end of the file. The base image specification (
FROM tonistiigi/binfmt:master AS builder) remains unchanged, which means there is no impact on functionality. The added newline adheres to common best practices and can help avoid potential issues with tools that expect a trailing newline.dockers/buildkit/syft/scanner/Dockerfile (1)
20-21: Formatting Improvement: Enforce trailing newline
The added newline at the end of the file ensures compliance with best practices and improves consistency across tools and environments, without affecting functionality.dockers/tools/benchmark/job/Dockerfile (1)
96-97: Standardizing the ENTRYPOINT Syntax
The removal of the hyphen before the ENTRYPOINT instruction brings the Dockerfile in line with standard syntax and improves consistency with similar files in the repository. There is no functional change here, and the updated syntax is clear and correct.internal/info/info_test.go (2)
339-342: New valdReplacer field added to the fields struct.The addition of the
valdReplacer *strings.Replacerfield to the test struct is consistent with what appears to be internal implementation changes. This suggests that the code under test now uses a string replacer, likely for formatting or sanitizing strings related to the Vald system.
425-431: Updated info struct initialization with the new valdReplacer field.The struct initialization has been properly updated to include the new
valdReplacerfield, maintaining consistency with the field declaration.apis/swagger/v1/vald/object.swagger.json (2)
17-18: Enhanced Documentation for/exists/{id}EndpointThe updated summary and description now provide a detailed table of status codes along with troubleshooting instructions. This comprehensive explanation will greatly help consumers understand and resolve potential errors.
106-107: Clear and Consistent Documentation for/object/{id.id}EndpointThe updated summary and description for the GetObject RPC clearly outline the expected status codes and provide detailed troubleshooting steps. This consistency with the
/exists/{id}endpoint is beneficial for overall documentation coherence.internal/config/benchmark_test.go (3)
22-22: Good addition of metadata support.Adding a
Meta map[string]stringfield to the test structure aligns with the new field likely added to the actualBenchmarkTargetstruct. This field will enable storing arbitrary metadata for benchmark targets, improving the flexibility of the benchmarking system.
49-49: Test case initialization for the new Meta field looks good.Both test case templates correctly initialize the new
Metafield tonil, which is appropriate for optional fields. This ensures future implementations of these tests will properly handle the metadata field.Also applies to: 70-70
103-103: Proper BenchmarkTarget initialization with the Meta field.The test object correctly assigns the field value from the test case to the
BenchmarkTargetinstance, ensuring the metadata will be properly passed to theBind()method when tests are implemented.apis/swagger/v1/vald/index.swagger.json (3)
38-38: Index Info Summary is Clear
The summary for/index/infonow states:
"summary": "Overview\nRepresent the RPC to get the index information."
This is clear and consistent with the desired documentation style.
59-59: Index Property Summary is Clear
The updated summary for/index/property(“Overview\nRepresent the RPC to get the index property.”) is descriptive and follows the new style.
80-80: Index Statistics Summary is Consistent
The summary for/index/statisticsnow includes an “Overview” prefix and a status code table, which is consistent with similar endpoints.apis/swagger/v1/vald/insert.swagger.json (1)
50-52: MultiInsert Documentation is Comprehensive
The updated summary and description for the/insert/multipleendpoint are very detailed. The inclusion of a structured status code table and troubleshooting guidance enhances clarity.apis/swagger/v1/vald/update.swagger.json (2)
17-19: Update Endpoint Documentation is Detailed
The summary for the/updateendpoint now reads:
"Overview\nUpdate RPC is the method to update a single vector.”
along with a descriptive status code table and troubleshooting block. This update is clear and informative.
50-52: MultiUpdate Endpoint Looks Good
The summary and description for the/update/multipleendpoint are consistent with other endpoints, providing all necessary details about status codes and error resolutions.apis/swagger/v1/vald/search.swagger.json (8)
17-19: LinearSearch Endpoint Documentation Update
The updated summary for the/linearsearchendpoint now reads:
"Overview\nLinearSearch RPC is the method to linear search vector(s) similar to the request vector...."
This expanded format—including the status code table and troubleshooting section—is clear and comprehensive.
50-52: LinearSearchByID Documentation is Detailed
The/linearsearch/idendpoint summary and description now provide explicit guidance on required pre-indexing and detail the expected error handling. This greatly improves usability.
83-85: MultiLinearSearchByID Documentation is Thorough
Both the summary and the description for the/linearsearch/id/multipleendpoint provide useful details—including a notice about gRPC message size limitations—and the structured table of status codes is a notable improvement.
115-119: MultiLinearSearch Documentation is Consistent
The updated summary for the/linearsearch/multipleendpoint follows the same pattern as the others, ensuring a uniform documentation style throughout.
149-151: Search Endpoint Documentation is Comprehensive
The/searchendpoint summary and description include a detailed status code table and troubleshooting guidance, ensuring that users have the necessary context for error handling.
182-184: SearchByID Endpoint Documentation is Clear
The expanded explanation for/search/id—including details about required pre-indexing—is very helpful.
215-217: MultiSearchByID Endpoint Documentation is Structured
The summary and description for/search/id/multipleprovide a clear and structured error table along with guidance, which is consistent with existing documentation standards.
248-250: MultiSearch Endpoint Documentation is Consistent and Informative
The updated summary and description for/search/multipledeliver the necessary troubleshooting details in a clear format.apis/swagger/v1/vald/flush.swagger.json (1)
17-17: Flush Endpoint Summary Enhancement
The summary for the DELETE operation on/flushnow includes an “Overview” prefix and a detailed status code table. This greatly improves clarity and matches the updated style used throughout the API documentation.apis/swagger/v1/vald/filter.swagger.json (6)
17-18: Enhanced Summary Documentation for/insert/objectEndpoint.
The updated summary now provides a detailed description with a status code table, which improves clarity regarding the InsertObject RPC.
49-50: Enhanced Summary for/insert/object/multipleEndpoint.
The updated summary offers additional context—including status code details—for the MultiInsertObject RPC, thereby aiding API consumers in understanding its behavior.
81-82: Enhanced Summary for/search/objectEndpoint.
The revised summary clearly outlines the purpose of the SearchObject RPC and provides a structured status code table, which aligns well with the overall documentation enhancements.
113-114: Detailed Summary for/search/object/multipleEndpoint.
The new summary not only details the bidirectional streaming capabilities but also includes a status code table. This enriches documentation for the StreamSearchObject RPC and ensures improved clarity.
145-146: Refined Summary for/update/objectEndpoint.
The updated summary now details the UpdateObject RPC with a comprehensive status code table, contributing to improved API guidance.
210-211: Enhanced Summary for/upsert/objectEndpoint.
The improved summary clearly explains the upsert behavior—covering both update and insertion actions—and includes an informative status code table, which enhances the endpoint documentation.apis/swagger/v1/vald/remove.swagger.json (3)
17-19: Expanded Documentation for/removeEndpoint.
The revised summary now incorporates a detailed status code table along with an added description that provides troubleshooting guidance. This enhancement should help API consumers diagnose common error scenarios effectively.
50-52: Detailed Summary and Description for/remove/multipleEndpoint.
The updated documentation clearly defines the MultiRemove operation and includes a troubleshooting section with common error resolutions, thereby enhancing the overall user guidance.
83-85: Enhanced Summary and Description for/remove/timestampEndpoint.
The updated summary and description now clearly outline the RemoveByTimestamp RPC’s behavior, including how multiple timestamps form anANDcondition, alongside troubleshooting tips. This provides a much-needed clarification for this specialized deletion operation.apis/swagger/v1/mirror/mirror.swagger.json (1)
17-18: Enhanced Summary for/mirror/registerEndpoint.
The new summary now provides a clear and detailed overview for the Mirror Register RPC, including a status code table, thus enhancing consistency with similar updates across the repository’s Swagger documentation.apis/docs/v1/docs.md (5)
1672-1674: Flush Service Overview Update
The overview succinctly describes that the Flush Service is responsible for removing all indexed and uncommitted vectors from thevald-agent. The description is clear and aligned with documentation standards.
1714-1716: Insert Service Overview Update
The inserted overview for the Insert Service is straightforward and effectively communicates its role in inserting new vectors into thevald-agent.
1778-1780: Remove Service Overview Update
The updated overview for the Remove Service clearly states its responsibility of removing vectors from thevald-agent. No further changes are needed.
1818-1820: Search Service Overview Update
The overview now explicitly identifies the Search Service’s role in finding vectors similar to a user request, which enhances understandability.
1940-1942: Upsert Service Overview Update
The overview effectively explains that the Upsert Service is responsible for updating existing vectors or inserting a new vector if it does not exist, which clearly communicates its dual functionality.internal/core/algorithm/usearch/usearch_test.go (2)
74-351: LGTM: Test_usearch_Search implementation is functional and well-structuredThe test implementation for the USearch search functionality is well-structured with clear test cases and proper setup/teardown. It properly tests various scenarios including successful vector searches and error conditions for dimension mismatches.
670-670:❓ Verification inconclusive
Mutex initialization changed from concrete instance to nil pointer
The change from using a concrete mutex instance to a nil pointer in these test struct definitions is consistent with a design pattern where the mutex is either initialized lazily or provided externally. This approach allows for more flexibility in testing scenarios.
However, ensure that any code using this mutex field checks for nil before attempting to use it, to prevent potential nil pointer dereferences:
Also applies to: 698-698, 801-801, 832-832, 932-932, 960-960, 1065-1065, 1097-1097, 1200-1200, 1231-1231, 1340-1340, 1372-1372, 1475-1475, 1506-1506, 1602-1602, 1630-1630
🏁 Script executed:
#!/bin/bash # Search for potential nil pointer dereferences of the mutex field # Look for direct uses of mu without nil check rg -A 5 -B 5 "\bmu\.(Lock|Unlock|RLock|RUnlock)" --type go # Look for initialization patterns rg -A 3 -B 3 "mu\s*[:=]\s*nil" --type goLength of output: 67338
Action Required: Confirm Nil Check Mechanisms for Mutex Field Usage
The change in
internal/core/algorithm/usearch/usearch_test.go(line 670) replaces a concrete mutex instance with a nil pointer to support a lazy or external initialization pattern. Our repository-wide search shows that many files use mutex methods (e.g.,Lock(),Unlock()) directly without any nil checks. Please verify that:
- Code paths that might engage the mutex field in tests (or when using this test struct) do not attempt to call methods on a nil pointer.
- Either the code that accesses this mutex explicitly guards against a nil value, or the test scenarios ensure that these method calls are not executed.
If necessary, add appropriate nil checks or document why these calls are safe given the test configuration.
dockers/buildbase/Dockerfile (1)
20-20: Formatting Change: Newline Addition.
The addition of a newline at the end of the file improves formatting consistency without affecting functionality.dockers/buildkit/Dockerfile (1)
20-20: Formatting Change: Newline Addition.
Adding a newline at the end reinforces best practices in file formatting.dockers/dev/Dockerfile (1)
143-143: Security Reminder: Running as Root.
The re-added commandUSER root:roottriggers a hadolint warning regarding running as the root user. While some development scenarios may require root privileges, consider using a non-root user for improved security in production builds.example/client/go.mod.default (1)
3-3: Go Version Upgrade.
Upgrading the Go version to1.24.2ensures that you benefit from the latest improvements and security fixes. Verify that all dependencies and build processes are compatible with this update.dockers/tools/cli/loadtest/Dockerfile (1)
96-96: Formatting Update: ENTRYPOINT Redefinition.
The redefinition of theENTRYPOINT ["/usr/bin/loadtest"]appears to be a formatting adjustment with no functional change.dockers/discoverer/k8s/Dockerfile (1)
89-89: Consistent ENTRYPOINT FormattingThe update to the
ENTRYPOINTinstruction (line 89) appears to be a formatting adjustment only, with no functional changes. This change improves consistency across Dockerfiles in the project.dockers/operator/helm/Dockerfile (1)
110-110: Maintained Functionality in ENTRYPOINTThe replacement of the
ENTRYPOINTinstruction (line 110) maintains the existing command while ensuring formatting consistency. No further modifications are needed.dockers/agent/core/faiss/Dockerfile (1)
99-100: Uniform ENTRYPOINT UpdateThe updated
ENTRYPOINT ["/usr/bin/faiss"]on lines 99-100 reflects a consistent formatting change with no alteration to the executed command. This aligns the Dockerfile with similar changes across the repository.dockers/gateway/mirror/Dockerfile (1)
89-90: Minor Formatting Update: ENTRYPOINT Instruction
The change to the ENTRYPOINT on line 89 is purely a formatting adjustment (ensuring a proper newline at the file’s end) and does not affect container functionality. This aligns the file’s style with the overall project consistency.dockers/manager/index/Dockerfile (1)
88-90: Consistent Formatting: ENTRYPOINT Instruction
The update in this Dockerfile involves a minor formatting change (newline adjustment in the ENTRYPOINT instruction) that does not change the container’s behavior. This contributes to uniform styling across Dockerfiles.dockers/index/operator/Dockerfile (1)
89-90: Formatting Consistency: ENTRYPOINT Instruction
The ENTRYPOINT line has been updated to include a final newline, a simple formatting change that does not alter functionality. This update improves consistency with other Dockerfiles in the repository.dockers/example/client/Dockerfile (1)
95-96: Minor Formatting Update: ENTRYPOINT Consistency
The slight modification ensuring a newline at the end of the ENTRYPOINT instruction is a non-functional, cosmetic change that aids in maintaining consistent file formatting throughout the project.dockers/agent/core/ngt/Dockerfile (1)
98-99: Formatting Update: ENTRYPOINT Instruction
The adjustment on line 98 to include a trailing newline after the ENTRYPOINT command is a formatting-only change. This update enhances consistency across Dockerfiles without any impact on container behavior.dockers/index/job/readreplica/rotate/Dockerfile (1)
89-90: Formatting Consistency for ENTRYPOINTThe update on line 89, which now directly specifies
ENTRYPOINT ["/usr/bin/readreplica-rotate"]
(with the trailing newline removed), improves consistency across similar Dockerfiles. There is no functional change, and the formatting now aligns with the rest of the project’s Dockerfiles.dockers/tools/benchmark/operator/Dockerfile (1)
89-90: Consistent ENTRYPOINT FormattingThe modified ENTRYPOINT on line 89 introduces a trailing newline (or, more accurately, fixes an omitted newline) to ensure consistent file formatting and consistency with related Dockerfiles. The command remains unchanged, and this update helps maintain uniformity in the project.
dockers/gateway/filter/Dockerfile (1)
89-90: Uniform ENTRYPOINT DeclarationThe change on line 89, which explicitly declares
ENTRYPOINT ["/usr/bin/filter"],
brings this Dockerfile in line with the formatting applied in other service Dockerfiles. This small update reinforces consistency without altering the container's behavior.dockers/index/job/creation/Dockerfile (1)
88-90: Streamlined ENTRYPOINT FormattingThe adjustment made at the end of the file—removing an extra newline while preserving
ENTRYPOINT ["/usr/bin/index-creation"]—is a purely cosmetic change that aids in file consistency. There is no impact on functionality.dockers/index/job/save/Dockerfile (1)
88-90: Consistent Dockerfile FormattingThe updated ENTRYPOINT on line 89 now reads
ENTRYPOINT ["/usr/bin/index-save"],
which removes an extraneous newline without affecting the container’s startup command. This minor change improves file uniformity across the codebase.dockers/gateway/lb/Dockerfile (1)
89-90: Formatting Consistency for ENTRYPOINT.
The addition of a newline after theENTRYPOINT ["/usr/bin/lb"]ensures that the Dockerfile formatting is consistent with other similar files. There is no change in functionality.dockers/agent/sidecar/Dockerfile (1)
88-89: ENTRYPOINT Formatting Update.
The updatedENTRYPOINT ["/usr/bin/sidecar"]now includes a newline at the end, matching the project’s style guidelines. The change is purely cosmetic and does not affect the container's behavior.dockers/index/job/correction/Dockerfile (1)
89-90: Consistent ENTRYPOINT Declaration.
A newline has been added after theENTRYPOINT ["/usr/bin/index-correction"]instruction. This update aligns the file’s formatting with the rest of the repository while preserving its intended functionality..github/ISSUE_TEMPLATE/security_issue_report.md (1)
20-26: Dependency Versions Updated.
The template now reflects the updated versions for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss. Please double-check that these versions match the versions used across the project to maintain consistency in your release documentation..github/ISSUE_TEMPLATE/bug_report.md (1)
26-32: Updated Environment Dependency Versions.
The bug report template has been revised to list the updated versions for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss. This ensures that all documentation templates remain aligned with the current dependency versions.internal/config/grpc.go (1)
186-186: Function name updated for clarityThe function name was changed from
WithOldConnCloseDurationtoWithOldConnCloseDelay, which improves clarity and matches the implementation ininternal/net/grpc/option.go. This is part of a broader refactoring for connection management.internal/config/config_test.go (1)
999-1003:❓ Verification inconclusive
Behavior change in file not found handling
The test case was updated to expect empty results when attempting to read non-existent files, whereas the previous test expected file contents. This reflects a change in how the
GetActualValuefunction handles missing files.Make sure this behavior change is documented, and check that no existing code depends on the old behavior:
🏁 Script executed:
#!/bin/bash # Search for usages of file:// pattern in the codebase that might depend on this behavior rg -A 2 -B 2 'file://' --type goLength of output: 1727
Action Required: Verify and Document New File-Not-Found Behavior
The updated tests confirm that when a file is missing,
GetActualValuenow returns an empty result instead of the previous fallback to file contents. A search forfile://usages shows no other code depending on the old behavior. However, the updated behavior isn’t explicitly documented in the function’s comment ininternal/config/config.go.
- Documentation: Please ensure that the behavior change (i.e., returning an empty result when the file does not exist) is clearly documented in the function’s comments or related documentation.
- Code Dependency: The grep results indicate no existing usages depend on the previous behavior.
internal/db/nosql/cassandra/option_test.go (1)
538-538: Error handling simplification is a good improvement.The error handling for invalid duration strings has been simplified across all test cases. This improves code readability and makes the error messages more direct.
Also applies to: 1524-1524, 1616-1616, 1708-1708, 1875-1875, 2980-2980, 3070-3070, 3925-3925
internal/net/grpc/pool/option_test.go (1)
449-450: Improved variable and function naming conventionThe function name and variable changes from
flgtoenableandTestWithOldConnCloseDurationtoTestWithOldConnCloseDelay(with associated references) improve code readability and consistency.Also applies to: 474-475, 493-494, 524-525, 872-874, 949-950
internal/file/file.go (3)
259-262: Enhanced error handling using new helper functionThe change from verbose
err != nil && !errors.Is(err, io.EOF)toerrors.IsNot(err, io.EOF)improves code readability using the new helper function.
374-391: New utility function for path handlingThe new
AbsolutePathfunction provides a consistent way to handle path conversions, which enhances maintainability. It properly handles edge cases like empty paths and ensures paths are properly cleaned.
564-565: Updated path joining to use the new AbsolutePath functionThe
Joinfunction now uses the newAbsolutePathfunction, providing more consistent behavior for path handling.internal/errors/errors.go (3)
86-88: Good addition of ErrUnimplemented.This follows the consistent pattern for error functions in the codebase and provides a standardized way to indicate unimplemented features.
170-180: Well-implemented IsAny function enhances error checking capabilities.The function properly handles edge cases (nil error, empty targets) and provides a clean way to check if an error matches any of multiple possible errors.
182-192: IsNot function complements IsAny and improves code readability.This function is a logical extension to IsAny and allows for more readable error-handling code as demonstrated in the discover.go change.
internal/client/v1/client/discoverer/discover.go (1)
290-290: Good use of the new IsNot function simplifies error checking.Replacing multiple
!errors.Is()calls with a singleerrors.IsNot()call improves code readability while maintaining the same functionality.internal/client/v1/client/discoverer/discover_test.go (1)
1578-1578: Commented code forupdateDiscoveryInfo.This reference to
c.updateDiscoveryInfois not actively tested. Verify if this is a placeholder for future tests; if not, remove the line to avoid confusion and maintain codebase cleanliness.internal/iter/iter.go (9)
29-38: Interface design is clear and modular.The
Cycle[S ~[]E, E any]interface cleanly separates iterator responsibilities (At, ForEach, etc.). This promotes testability and flexible usage.
42-49: Struct fields are well-labeled.The
cyclestruct effectively stores iteration metadata (start,num,size,offset,array,modFunc). Good job documenting each field’s role in comments.
51-68: Well-structured constructor with offset handling.
NewCycleproperly checks fornilarrays and zero lengths, then calculates the start index. This ensures safe usage. Ifnumis often larger than the array size, consider clarifying that repeated cycles are intentional in the documentation.
80-94:Seq2usage is straightforward.The method creates a generator that checks
ctx.Done()for each iteration and yields(index, value). This robust approach prevents blocking and respects context cancellations.
96-114: ConsistentSeqandValuesapproach.Both generate simple sequences for iteration. Nice synergy with
Seq2. The fallback toValues(ctx)forSeq(ctx)helps maintain a consistent API.
116-130:Indexesmethod parallels logic for index-only yields.The approach mirrors
Valueswith index-only results. Clean and uniform design, ensuring all variants of iteration are covered.
132-143:ForEachmethod with early-break logic is appropriate.Gracefully halting on
falsereturn or context cancellation is well executed. The function signature is easy to use for typical iteration patterns.
145-147:Rawusage is clear and correct.Returning the original slice allows direct manipulation if needed, while users can still iterate with the other methods for convenience.
149-152:Lenreturns the intended iteration length.Using
c.numis consistent with the cycle’s intended iteration count, not just the underlying slice’s size. This clarifies the difference between the slice length and the number of elements to iterate.apis/swagger/v1/vald/upsert.swagger.json (4)
17-17: Comprehensive summary for/upsert.Enhancing the summary with status codes, troubleshooting steps, and usage notes improves clarity for API consumers.
18-18: Detaileddescriptionoffers meaningful guidance.The added table of common errors with resolutions is highly valuable. This level of detail saves users time in debugging.
50-50: Good clarity on multi-vector upsert scope.Emphasizing “in 1 request” clearly indicates that multiple vectors are handled simultaneously, which is crucial for performance considerations.
51-51: Helpful note on gRPC limits and error table.The note about gRPC’s message size limitation, combined with the troubleshooting table, ensures robust documentation that addresses potential pitfalls.
internal/net/grpc/pool/option.go (6)
37-37: Function renamed fromWithOldConnCloseDurationtoWithOldConnCloseDelay.The function has been renamed for better clarity, and the internal field has been updated from
p.oldConnCloseDurationtop.oldConnCloseDelay. This change makes the function name more descriptive of its purpose.Also applies to: 139-149
42-53: Improved address handling with better error management.The
WithAddrfunction now attempts to split the host and port usingnet.SplitHostPortand handles the error case appropriately by setting only the host when splitting fails. This enhancement improves the robustness of the function.
92-96: Parameter name change improves readability.The parameter name
flghas been changed toenablein theWithResolveDNSfunction, and the field name has been updated fromp.resolveDNStop.enableDNSLookup. These changes make the code more self-descriptive and consistent with the function's purpose.
114-114: Field name changed fromp.sizetop.poolSize.This change improves code clarity by using a more descriptive field name.
130-135: Simplified error handling inWithDialTimeout.The error handling has been improved by directly assigning the parsed time value to
p.dialTimeoutwhen no error occurs, instead of using a separateif err == nilblock.
155-155: Field name changed fromp.egtop.errGroup.Using a more descriptive field name improves code readability.
.github/workflows/codeql-analysis.yml (1)
46-96: Modernized CodeQL workflow with enhanced configuration and flexibility.The workflow has been significantly improved by:
- Upgrading to CodeQL action v3 from v2
- Implementing a language-matrix strategy for better flexibility
- Adding proper permission controls
- Including container credentials for secure image access
- Making the autobuild step conditional on the Go language
These changes align with best practices for GitHub Actions workflows and security scanning.
.gitfiles (6)
126-126: Added new E2E testing framework files.This change adds a comprehensive set of files for the new E2E testing framework located in
tests/v2/e2e/, which aligns with the PR objective of enhancing testing maintainability. The framework appears to include support for configuration, dataset handling, Kubernetes integration, and port forwarding.Also applies to: 2035-2055
1088-1088: Added new iterator abstractions package.The addition of
internal/iter/iter.gointroduces iterator abstractions, which should improve code reusability and maintainability as mentioned in the PR objectives.
1051-1051: Enhanced error handling with new params file.This aligns with the PR objective of improving error handling in the
internal/errorspackage.
1274-1274: Added QUIC protocol support with new files.The new files for QUIC protocol indicate network enhancements for potentially faster and more reliable communication.
The filename contains "quic" which is flagged by the spellchecker, but this is correct as it refers to the QUIC network protocol.
Also applies to: 1276-1276
1966-1966: Added Rust handler for object operations.The new object handler adds functionality to the Rust implementation, improving cross-language support in the codebase.
Based on past learnings, please ensure this Rust handler properly handles None values explicitly without using
unwrap()on Option types. Return appropriate error statuses instead for robustness.
1986-1990: Added support for QBG algorithm in Rust.This adds support for the Quantized Binary Graph (QBG) algorithm implementation in Rust, extending the system's capabilities for vector search.
example/client/go.mod (4)
3-3: Go version updateThe Go version has been updated from 1.24.0 to 1.24.2, which includes bugfixes and security improvements.
10-18: Dependency updates in replace directivesThe updated dependencies include security fixes and improvements:
- github.com/pkg/sftp from v1.13.7 to v1.13.9
- golang.org/x packages (crypto, net, text)
- google.golang.org packages (grpc, protobuf, genproto)
These updates align with the broader effort to maintain up-to-date dependencies across the project.
28-28: Updated gRPC version in require sectionThe gRPC version has been updated from v1.67.1 to v1.71.0, which might include API improvements and bug fixes.
36-41: Updated indirect dependenciesIndirect dependencies have been updated to maintain compatibility with the direct dependency changes.
.github/workflows/coverage.yaml (1)
45-47: Added container registry authenticationContainer registry credentials have been added to the GitHub workflow, improving security by authenticating with the registry using secrets. This change is consistent with the updates in other workflow files.
.github/workflows/build-binaries.yaml (1)
34-36: Added container registry authenticationContainer registry credentials have been added to the GitHub workflow, improving security by authenticating with the registry using secrets. This change is consistent with the updates in other workflow files.
Makefile.d/e2e.mk (1)
22-25:✅ Verification successful
Added new E2E test target for V2 framework
A new target
e2e/v2has been added to the Makefile that runs the new V2 testing framework with theTestE2EStrategytest. This is part of the PR's objective to implement a more maintainable E2E testing framework.Run the following to verify that the referenced
run-v2-e2e-crud-testfunction is properly defined in the codebase:
🏁 Script executed:
#!/bin/bash # Search for the run-v2-e2e-crud-test function definition fd functions.mk --exec grep -A 15 "run-v2-e2e-crud-test" {} \;Length of output: 545
Verified: E2E/v2 Target and Function Definition
Thee2e/v2target inMakefile.d/e2e.mkcorrectly callsrun-v2-e2e-crud-testwith the appropriate parameters. The function definition infunctions.mkwas found and verified to properly set up all necessary variables before invokinggo testwith the provided argument (i.e.,-run TestE2EStrategy). No issues were found with this integration..github/workflows/unit-test-rust.yaml (1)
44-46: Container credentials added for security enhancement.Adding these container credentials is a good security practice for authenticating with GitHub Container Registry when pulling the CI container image.
dockers/index/job/deletion/Dockerfile (1)
89-89: LGTM - Minor formatting change.This change appears to just be adding a newline at the end of the file, with no functional changes to the Dockerfile's behavior.
.github/workflows/e2e-profiling.yaml (1)
45-47: Container credentials added for security enhancement.Adding these container credentials is a good practice for authenticating with GitHub Container Registry. This is consistent with similar credential additions in other workflow files, showing a systematic approach to improving security across the CI/CD pipeline.
internal/net/grpc/status/status.go (1)
48-50: Added useful helper for gRPC error code verification.This
Isfunction provides a convenient way to check if a gRPC error has a specific status code. It enhances code readability by expressing the intent more clearly than direct comparisons would.Makefile.d/tools.mk (2)
215-216: Improved build configuration for zlibAdding the CMake policy version minimum parameter ensures consistent CMake behavior across different environments. This is a good practice to maintain build stability.
244-245: Consistent CMake policy configuration for hdf5The same CMake policy version parameter was applied here as with zlib, ensuring consistency across library builds. This is a good approach to maintain uniform build configurations.
.github/workflows/fossa.yaml (1)
39-41: Added container credentials for security enhancementAdding credentials for accessing the container registry is a security best practice. Using GitHub secrets for storing sensitive information is the appropriate approach.
.github/workflows/e2e-max-dim.yaml (1)
43-45: Added container credentials for security enhancementAdding authentication credentials for container access enhances security by ensuring that only authorized users can pull the container image. This aligns with the changes made in other workflow files.
dockers/agent/core/agent/Dockerfile (1)
97-97: No functional change in ENTRYPOINT definitionThe ENTRYPOINT directive appears to have been moved or reformatted without any functional change to its content. This maintains the existing container behavior while aligning with the formatting standards in the project.
.github/workflows/test-hack.yaml (1)
58-60: Enhanced container security with registry authenticationAdding credentials to access the container registry is a good security practice. This change ensures proper authentication with the GitHub Container Registry (ghcr.io) when pulling the CI container image.
.github/workflows/reviewdog.yaml (2)
35-37: Authentication added for container registryAdding credentials for the golangci-lint job container ensures proper authentication with the GitHub Container Registry. This is consistent with the changes made in other workflow files.
57-59: Authentication added for container registryAdding credentials for the go-build job container ensures proper authentication with the GitHub Container Registry. This is consistent with the changes made in other workflow files.
.github/workflows/unit-test.yaml (3)
54-56: Authentication added for container registryAdding credentials for the test-cmd job container ensures proper authentication with the GitHub Container Registry. This is consistent with the changes made in other workflow files.
74-76: Authentication added for container registryAdding credentials for the test-internal job container ensures proper authentication with the GitHub Container Registry. This is consistent with the changes made in other workflow files.
94-96: Authentication added for container registryAdding credentials for the test-pkg job container ensures proper authentication with the GitHub Container Registry. This is consistent with the changes made in other workflow files.
Makefile.d/minikube.mk (1)
28-29: Ensure consistent Minikube driver usageExplicitly setting the Docker driver for Minikube ensures consistent behavior across different environments. This is a good change as it:
- Makes the driver choice explicit rather than relying on defaults
- Ensures the same virtualization backend is used consistently
- Aligns with the E2E testing framework's needs mentioned in the PR description
This change should help with the maintainability focus of the PR.
.github/workflows/helm.yaml (2)
38-40: Secure Credential Injection for Helm Chart Update Container
The newcredentialsblock added to theupdate-helm-chartjob enables secure authentication by sourcing the username and password from GitHub secrets. This aligns with best practices for containerized CI jobs.
83-85: Credential Setup for Remote Helm Chart CRUD Job
The addition of thecredentialsblock in thecrud-on-remote-helm-chartjob ensures secure access when performing CRUD operations. Please verify that the secrets (PACKAGE_USERandPACKAGE_TOKEN) are correctly set in the repository..github/workflows/helm-lint.yaml (3)
35-37: Credential Configuration for Vald Chart Linting
The insertion of thecredentialsblock under the container section for thelint-vald-chartjob correctly enables authenticated access. Ensure that these credentials are kept secure and up to date.
56-58: Secure Credentials for Helm-Operator Chart Linting
The new credentials for thelint-vald-helm-operator-chartjob follow the same security pattern, which is good for consistency across jobs.
77-79: Credential Setup for Values Schema Linting
Adding the credentials block to thelint-values-schemajob ensures that the container can access necessary resources securely. Verify that the additional options (e.g., the add-host option) continue to work as intended..github/workflows/e2e-code-bench-agent.yaml (2)
61-63: Credential Implementation for gRPC Sequential Job
The newcredentialsfield in the container section of thegrpc-sequentialjob securely injects the username and password. This update helps align with the updated security practices across workflows.
91-93: Credential Addition for gRPC Stream Job
The inclusion of thecredentialsblock for thegrpc-streamjob ensures consistent security measures are applied across all E2E benchmark jobs. Please ensure that the credentials provided are valid and maintained..github/PULL_REQUEST_TEMPLATE.md (1)
19-25: Version Number Updates in PR Template
The version numbers for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss have been updated to the new versions. This helps in keeping documentation in sync with the environment changes. Make sure that these version updates are reflected elsewhere in the documentation and tested accordingly.internal/net/grpc/option.go (1)
656-663: API Renaming: WithOldConnCloseDelay
The function has been renamed fromWithOldConnCloseDurationtoWithOldConnCloseDelayfor improved clarity. The implementation remains straightforward, but please ensure all call sites in the codebase have been updated to use the new name to avoid potential runtime issues..github/workflows/_release-pr.yaml (1)
44-46: Improved security for container accessThe addition of credentials for accessing the container registry enhances security by ensuring authenticated access to the container images. This is good practice for accessing private container registries.
.github/workflows/e2e-chaos.yaml (4)
47-49: Secure container access implementationAdding credentials for the container registry is a good security practice. This ensures proper authentication when pulling the container image for the chaos test workflow.
91-93: Consistent credential implementationThe credentials addition follows the same pattern as in the agent-failure job, maintaining consistency throughout the workflow file.
135-137: Secure authentication for container imagesProper credentials for container access have been added, consistent with other jobs in this workflow.
179-181: Completed credential implementationThe credentials have been consistently added to all job containers in the workflow, completing the security enhancement for container image access.
.github/workflows/reviewdog-k8s.yaml (3)
36-38: Enhanced container securityAdding credentials for the container registry ensures secure access to the container image, which is a good security practice.
59-61: Consistent credential implementationThe credentials have been added consistently with the same pattern as in other jobs, maintaining uniformity throughout the workflow.
81-83: Completed credential implementationAuthentication credentials have been added to all container configurations in this workflow, completing the security enhancement consistently.
internal/backoff/backoff_test.go (1)
63-63: Update test case to reflect new default behaviorThe change from
errLog: truetoerrLog: falsealigns with the removal ofWithEnableErrorLog()option from thedefaultOptionsininternal/backoff/option.go, ensuring the test correctly validates the new default configuration where error logging is disabled by default..github/workflows/_docker-image.yaml (1)
73-83: Enhanced container registry authenticationAdding explicit login steps for DockerHub and GitHub Container Registry before the build process is a security improvement. This ensures proper authentication for both pulling base images and pushing built images.
.github/workflows/update-deps.yaml (1)
34-36: Added container credentials for secure image pullsAdding container credentials improves security by ensuring authenticated access to the container registry when pulling the CI container image. This is a good practice and consistent with security improvements across other workflow files.
.github/workflows/chatops.yaml (1)
32-34: Standardized container authentication across ChatOps jobsThe addition of container credentials across all jobs in the ChatOps workflow ensures consistent, secure access to container images. This systematic approach to authentication is an important security improvement for the CI/CD infrastructure.
Also applies to: 85-87, 165-167, 281-283, 416-418
internal/backoff/backoff.go (2)
22-22: Good addition of the maps package.Using the standard library's maps package allows for more concise code and potentially better performance.
244-244: Excellent refactoring using maps.Clone().This change simplifies the code by replacing manual map iteration and copying with the more concise and potentially more efficient
maps.Clone()function. The functionality remains the same while improving readability and maintainability.- m := make(map[string]int64, len(metrics)) - for k, v := range metrics { - m[k] = v - } - return m + return maps.Clone(metrics)internal/net/grpc/server_test.go (2)
29-29: LGTM: Import of gRPC proto encoding.Adding this import is good preparation for using proto encoding in gRPC server tests.
837-1176: Future test functions for server options.These commented-out test structures provide good templates for testing server options when they're ready to be implemented. They follow a consistent pattern with the existing tests in the file.
Consider implementing these tests in a follow-up PR to improve test coverage for these server options.
.github/workflows/format.yaml (3)
36-38: Improved security by adding container authentication credentials.The addition of container authentication credentials using GitHub secrets is a secure practice that ensures only authorized users can access the container image.
95-97: Approved consistent authentication pattern.The same authentication pattern is correctly applied to the
check-format-diffjob, maintaining consistent security practices across the workflow.
108-109: Enhanced format command with additional targets.The formatting command now includes multiple targets (
license,format,format/go,format/go/test) which provides more comprehensive code formatting and license checking. The checkout list has also been updated to include Rust toolchain files, ensuring proper handling of Rust components.internal/net/grpc/errdetails/errdetails.go (10)
26-26: Added missing import for conversion utilities.The addition of the
github.com/vdaas/vald/internal/convimport supports the enhanced error handling in the file.
35-35: Added protojson for improved serialization.The addition of the
google.golang.org/protobuf/encoding/protojsonimport is necessary for handling protobuf message serialization in the default case of marshaling.
80-82: Good addition of structured Details type.The new
Detailstype provides a clear structure for encapsulating error details, which improves the API and ensures consistent representation of error details in JSON/YAML.
93-94: Improved string trimming for better type URL handling.The updated implementation now consistently handles both standard and v1 prefixes in the type URL, which provides better flexibility for different message types.
165-173: Enhanced error handling with improved logging.The updated error handling now includes better logging for failed marshal operations, providing more context for debugging. The inclusion of type name and detailed objects in the log message makes troubleshooting easier.
316-318: Improved Serialize function with structured output.The updated Serialize function now uses the new Details struct for consistent handling of multiple messages, providing a more structured output format.
322-322: Simplified string conversion using conv package.Using
conv.Btoa()instead of directly working with byte slices improves code readability and maintainability by leveraging a dedicated utility function.
330-331: Consistent type URL handling for error details.Similar to the improvements in the MarshalJSON method, the AnyToErrorDetail function now handles both standard and v1 prefixes consistently.
416-421: Added fallback handling for unknown message types.The addition of a default case to attempt unmarshaling unknown message types enhances robustness and makes the code more flexible when dealing with various message formats.
424-424: Improved error logging with type information.Similar to the enhanced error handling in MarshalJSON, this change improves error logging by including typeName in the log message, providing better context for troubleshooting.
internal/net/grpc/client.go (12)
173-179: Improved error handling with consolidated IsNot check.The code now uses
errors.IsNot()to check for multiple error types in a single call, replacing multiple separateerrors.Is()negated checks. This improves code readability and maintainability by reducing repetition and making the logic more explicit.
261-266: Consistent error handling pattern applied.The same pattern of consolidated error checking is applied for connection rebalancing, maintaining consistency in the error handling approach throughout the file.
299-307: Consolidated error checks for health check reconnection.The health check reconnection error handling follows the same improved pattern, ensuring a consistent approach to error management across different parts of the client implementation.
374-382: Consistent error handling in Disconnect method.Error handling in the Disconnect method has been updated to follow the same pattern, which helps maintain consistency across the codebase.
480-481: Improved context cancellation checks with IsAny.Using
errors.IsAny()to check for both context cancellation and deadline exceeded errors simplifies the code by consolidating multiple checks into a single function call.
503-504: Consistent context error checking with IsAny.The pattern of using
errors.IsAny()for context-related errors is consistently applied throughout the code, improving maintainability.
753-763: Enhanced error handling in RoundRobin method.The error checking in the RoundRobin method follows the same improved pattern, providing consistent error handling throughout the client implementation.
853-864: Improved error checks in connectWithBackoff.The same pattern is applied in the connectWithBackoff method, ensuring consistency in the error handling approach throughout the client implementation.
888-894: Consistent error handling with circuit breaker.Error handling with the circuit breaker follows the same improved pattern, which helps maintain a consistent approach to error management.
983-986: Simplified error check in Connect method.The Connect method uses a single
errors.IsNot()check for clearer error handling compared to the previous approach, maintaining consistency with the rest of the file.
994-997: Consistent error handling in disconnect operation.Error handling in the disconnect operation within the Connect method follows the same pattern, ensuring consistency across the codebase.
1090-1093: Simplified error check in Close method.The Close method uses a single
errors.IsNot()check for clearer error handling, maintaining consistency with the rest of the file.Makefile (8)
163-163: Improved optimization flags for better control and consistency.Changed from
-Ofastto-O3 -ffast-mathwhich provides the same level of optimization but with more explicit control over floating-point behavior. This is a safer approach that maintains performance while being more standards-compliant.
167-167: Added math library linking in HDF5_LDFLAGS.Explicitly added
-lmto ensure proper linking with the math library, which is good practice for HDF5 operations that often rely on mathematical functions.
169-169: Simplified TEST_LDFLAGS with CGO_LDFLAGS.Using the consolidated CGO_LDFLAGS variable instead of explicitly listing FAISS_LDFLAGS and HDF5_LDFLAGS improves maintainability by centralizing these settings.
355-356: Added E2E testing configuration variables.These new variables support the E2E testing framework mentioned in the PR objectives, properly configuring the test environment with default paths and addresses.
470-476: Improved .gitfiles generation with header preservation.The updated implementation preserves the first 15 lines of the existing .gitfiles file when it exists, which likely maintains important header information while still updating the file list.
552-562: Enhanced Go formatting with better source file selection.Changed from using
findto using the centralized.gitfileslist filtered with grep, which is more efficient and consistent. Also added helpful output messages to indicate formatting progress.
571-581: Similar improvements for test file formatting.Applied the same improvements to the test file formatting target, ensuring consistency between regular and test file formatting processes.
702-702: Standardized CMake policy versioning.Replaced hardcoded CMake policy version with the variable
$(CMAKE_VERSION), ensuring consistent versioning across different build operations and simplifying future version updates.Also applies to: 724-724, 748-748
internal/config/config.go (4)
66-66: Enhanced type safety with generics in Read function.The Read function now uses a generic type parameter
T anyinstead of the less type-safeanyparameter. This maintains backward compatibility while providing better compiler-time type checking.
99-115: Added generic constraints to GetActualValue for better type flexibility.The function now uses
T ~stringconstraint, allowing it to operate on any string-compatible type while maintaining strong typing. The implementation properly handles type conversions while preserving the original functionality.
120-125: Extended GetActualValues with generic type support.Similar to GetActualValue, this function now supports any string-like type through generics, making it more versatile while maintaining type safety.
128-130: Added generic support to checkPrefixAndSuffix helper function.The helper function now supports the same generic types as the functions it supports, with appropriate type conversions to maintain the original functionality.
hack/go.mod.default (4)
3-3: Updated Go version to 1.24.2.Minor version upgrade from 1.24.0 to 1.24.2, which likely includes important bug fixes and security patches.
16-16: Simplified dependency management with upgrade directive.Changed specific version pinning to use the
upgradedirective for several dependencies, allowing the package manager to select the latest compatible version automatically.Also applies to: 134-134
332-337: Updated Kubernetes dependencies to v0.32.3.All Kubernetes-related dependencies have been updated from v0.32.0 to v0.32.3, ensuring consistent versioning across the Kubernetes ecosystem components.
Also applies to: 340-341
344-344: Updated controller-runtime and structured-merge-diff.Updated
controller-runtimefrom v0.19.3 to v0.20.4 andstructured-merge-diff/v4from v4.5.0 to v4.6.0, keeping pace with the Kubernetes ecosystem updates.Also applies to: 347-347
internal/net/grpc/option_test.go (3)
3261-3344: Function rename: WithOldConnCloseDuration → WithOldConnCloseDelayThe test function has been renamed from
TestWithOldConnCloseDurationtoTestWithOldConnCloseDelay, which indicates a naming change in the actual implementation. This is clearer as it specifies that it's a delay parameter rather than a generic duration.
2581-3174: New test functions added for comprehensive option testing.Several new test functions have been added:
TestWithAuthorityTestWithDisableRetryTestWithIdleTimeoutTestWithMaxCallAttemptsTestWithMaxHeaderListSizeTestWithSharedWriteBufferTestWithUserAgentThese additions improve test coverage for gRPC client options, which aligns with the PR's goal of improving maintainability.
532-3344:❓ Verification inconclusive
Test functions have been extensively renamed and parameters changed, but implementations remain commented out.
The file contains numerous test function renames and parameter type changes, but most test implementations remain commented out with
TODOmarkers. This pattern suggests a significant refactoring of the option functions while preserving the test structure, but the tests themselves are not fully implemented.Ensure that there are corresponding implementation changes in the related option functions that match these test renames. For example, verify that
WithBackoffMaxDelaynow exists and accepts astringparameter rather than[]grpc.DialOption.
🏁 Script executed:
#!/bin/bash # Check if the implementation functions exist in the codebase for func in "WithBackoffMaxDelay" "WithBackoffBaseDelay" "WithBackoffMultiplier" "WithBackoffJitter" "WithOldConnCloseDelay"; do echo "Searching for $func implementation..." rg -A 1 "func $func" --type go | grep -v "_test.go" doneLength of output: 2485
Implementation functions verified; tests still pending implementation.
The refactoring correctly updates the option functions. For example, the implementations forWithBackoffMaxDelay,WithBackoffBaseDelay,WithBackoffMultiplier,WithBackoffJitter, andWithOldConnCloseDelayin the codebase now accept parameters of the expected types (e.g., astringfor delay durations). This confirms that the refactor of the option function interfaces was performed as intended.However, note that almost all test cases remain commented out with
TODOmarkers. You should consider providing actual test implementations soon to ensure these changes are validated at runtime.internal/net/grpc/pool/pool.go (27)
34-35: Imports for gRPC status and codes.
The addition ofcodesandstatusimports is a good practice for robust error handling. No issues found here.
79-121: Check potential infinite loop in connection closure.
TheClosemethod uses a loop that callsconn.Close()repeatedly until the connection state becomesShutdownor the context times out. This approach should be safe due to the context timeout, but ensure testing covers edge cases where GRPC channels remain stuck in transient states.
123-128: Struct-level documentation is clear.
The overall doc comment explainingpool’s relationship to theConninterface is concise and helpful.
129-158: Configuration fields are self-explanatory.
The field naming is consistent, and comments describing each field are helpful. Pay attention to concurrency aspects ofatomic.Pointerusage, ensuring all read/writes go through consistent patterns.Would you like to run a script that checks all usages of
connSlotsto confirm each is viaLoad()orStore()?
160-161: Default pool size value.
const defaultPoolSize = uint64(4)is a reasonable starting default. No concerns here.
163-164: Global metrics.
Storing metrics in a global map is straightforward. However, consider concurrency if updating from multiple pools. Checking for atomic or locked increments may be beneficial.
166-254: New(...) constructor refactoring.
The constructor covers address parsing, fallback scanning, and slot initialization. That’s helpful.
- Ensure we handle the scenario where
portremains zero after scanning.- Confirm that
dialTimeoutandoldConnCloseDelayare strictly greater than zero in all usage.
256-265: Pool init function.
Initialization logic is clear: verifying minimum pool size and preparingconnSlots. Implementation looks solid.
275-286: grow() function.
This function copies the old slots into a new, larger slice. It looks correct. Just be mindful of concurrency ifgrow()is invoked while other goroutines doloop()orstore(). The approach with atomic pointer to the slice is generally safe, but recheck any race conditions.
288-295: load() method.
No issues in logic. It’s aligned with the atomic slice usage. Just ensure indexing is always valid if concurrency changes pool size frequently.
297-305: store() method.
Similar toload(). The store is correct. No immediate concerns.
332-335: slotCount().
Simple wrapper giving the slice length. No issues here.
337-340: flush().
flush()setsconnSlotsto nil. It effectively discards references to old connections, relying on the caller to handle final closure. Implementation is consistent with the usage inDisconnect().
387-409: Connect(): DNS-based vs. single-target logic.
The distinction between IP-based single target and DNS-based addresses is well-defined. The fallback tosingleTargetConnect()if DNS resolution fails is especially helpful.
410-434: connect() multi-IP approach.
Looping through IP addresses with round-robin assignment is logical. The concurrency model for partial successes looks well-handled.
436-457: singleTargetConnect() improvements.
Works similarly toconnect(), focusing on one address. The condition that if enough slots fail, it short-circuits is a good optimization.
459-485: Reconnect() method.
Nicely checksforceor whether the pool has changed IP addresses. If the pool is still healthy, it does nothing. This is more efficient than forcibly reconnecting every time.
487-513: Disconnect() flow.
The method setsclosingto true and then attempts a graceful closure of each slot. Once done, it callsflush(). That seems correct.
515-557: dial() with optional backoff.
The fallback to a backoff function is useful for ephemeral networking issues. Verifyingconnhealth immediately after creation is also a nice safeguard.
559-582: getHealthyConn(): Round-robin retrieval.
The code checks up topoolSizetimes. This is a typical approach. The forced refresh upon unhealthy detection is a neat fallback.
597-604: Get() method.
Returns a single healthy connection or false. Implementation is minimal and correct.
635-638: Len() method.
A direct alias toslotCount(). Implementation is fine.
640-643: Size() method.
Loads the stored pool size. Straightforward usage ofatomic.Uint64.
645-648: IsIPConn() method.
Returns theisIPAddrflag. Straightforward.
650-659: String() for debugging.
Great to see a comprehensive string representation that includes the pool’s internal state (dnsHash, isIP, etc.).
725-738: Metrics() function.
Returns a snapshot of the healthy connection count. Straightforward usage ofsync.Map. No immediate concerns.
740-770: p.isHealthy() internals.
Good logic for GRPC connectivity states. The additional attempt toconn.Connect()when idle helps keep connections warm. Ensure repeated calls do not spawn indefinite goroutines if the connection remains idle.go.mod (2)
3-3: Go version updated to 1.24.2.
Ensure that your build environment and CI pipeline fully support Go 1.24.2.
423-544: Indirect dependencies also changed.
Make sure there are no hidden breaking changes in these indirect versions, especially around code generation or instrumentation libraries like Opentelemetry.
There was a problem hiding this comment.
Actionable comments posted: 7
🔭 Outside diff range comments (1)
internal/config/config.go (1)
66-94: 🛠️ Refactor suggestionPotential type constraint issue for
Read[T any].
IfTis not a pointer,yaml.Unmarshalorjson.Decodecould fail or silently produce incorrect results. It may be safer to enforceTas a pointer type in the function signature.-func Read[T any](path string, cfg T) (err error) { +func Read[T any](path string, cfg *T) (err error) {
🧹 Nitpick comments (26)
internal/errors/params.go (1)
17-21: New Error Variable Addition.
A new error variableErrArgumentParserNotFoundis introduced using the existingNewconstructor. To improve clarity for future maintainers, consider adding a brief comment above this variable to describe when or why it should be used.internal/errors/errors_test.go (1)
1737-1826: New test function scaffold for error comparison functionality.This added test stub provides a framework for testing the internal
isfunction which appears to handle error comparison with various error types. The scaffold follows the project's standard test pattern and will help ensure proper error comparison behavior once implemented.While the test function is currently commented out, I recommend ensuring it gets completed in a future PR to improve test coverage of the error handling subsystem, especially if the
isfunction is critical to the error comparison logic.internal/info/info_test.go (1)
996-1094: Implement the TODOs in the new test functionThis new test function
TestStackTrace_ShortStringis well-structured but contains only TODOs without actual test implementations. Consider implementing these test cases to ensure theShortStringmethod functions correctly.Would you like me to help generate some test implementations for this function based on how
ShortStringshould behave?internal/file/file_test.go (1)
1523-1607: Consider adding actual test cases forTestAbsolutePath.
Although the function scaffold is present, the body contains only commented-out placeholders. Implement robust test scenarios to verify both valid and invalid path inputs, ensuring broader coverage.I can help create a few sample test cases if desired.
internal/errors/k8s.go (1)
20-46: Great job organizing error variables into a grouped declaration for improved readability.The consolidated error variable declarations improve code structure and maintenance. However, there are a couple of inconsistencies in the error message capitalization:
ErrUndefinedNamespaceandErrUndefinedServicestart with uppercase "Undefined", while all other error messages start with lowercase.- ErrUndefinedNamespace = New("Undefined namespace") + ErrUndefinedNamespace = New("undefined namespace") - ErrUndefinedService = New("Undefined service") + ErrUndefinedService = New("undefined service")cmd/index/job/deletion/main_test.go (1)
1-86: Test scaffold ready for implementationThis appears to be a well-structured test scaffold for the deletion job's main function. The table-driven test approach with support for concurrency, goroutine leak detection, and cleanup functions follows Go testing best practices.
Would you like me to help implement actual test cases for this scaffold? I can suggest test scenarios based on the main function's behavior and dependencies.
internal/config/index_deleter_test.go (1)
1-140: Well-structured test scaffold for IndexDeleter.Bind methodThe test scaffold provides a comprehensive structure for testing the IndexDeleter's Bind method with all necessary fields. The deep equality check using reflect.DeepEqual is appropriate for validating the binding functionality.
Would you like me to help implement test cases for different binding scenarios? I could suggest test cases covering various field combinations and edge cases.
apis/swagger/v1/vald/upsert.swagger.json (1)
50-52: Improved /upsert/multiple endpoint details
The summary and description have been updated to clearly state that the multi-upsert operation combines update and insert in one request and now includes a notice about gRPC message size limitations. Verify that the HTML block (using<div class="notice">) renders as expected across all documentation viewers.internal/net/grpc/pool/pool.go (4)
460-485: Force reconnection logic verification.
Whenforceis true, this method restarts connections unconditionally. Confirm that no side effects occur if multiple threads callReconnect(ctx, true)in parallel. It might be prudent to add concurrency guards or coordinated checks to avoid frequent teardown-and-reconnect cycles.
488-513: Graceful disconnection feedback.
DuringDisconnect, each connection slot is closed witholdConnCloseDelay. If some connections remain in an intermediate state for an extended time, the user might not realize the final disconnection status. Consider adding an explicit log or metric capturing the pool’s final shutdown status if this is critical to operations.
559-582: Round-robin retrieval with fallback.
The round-robin indexing forgetHealthyConnprovides even load distribution. If no healthy connection is found, the code attempts to refresh the slot. This is beneficial but potentially expensive in high-throughput scenarios. Consider caching the last known healthy connection to avoid repeated dial attempts.
606-633: All-or-some healthy logic.
For IP-based connections, this method requires all slots to be healthy; for others, at least one. This is a good approach, though confirm that external usage expects this distinction. Some systems might still prefer a partial healthy fallback if certain IP connections are failing but others remain valid.apis/swagger/v1/vald/search.swagger.json (1)
182-183: Descriptive search-by-ID guidance.
Provided instructions on ensuring vectors are indexed first. Consider referencing any relevant “insert” documentation link to unify the workflow for readers.apis/docs/v1/docs.md (9)
1372-1378: Mirror Service Overview and Table Formatting
The added overview for the Mirror service clearly communicates its responsibility for providing theRegisterinterface for the Vald Mirror Gateway. However, the table that follows appears cluttered with extra formatting symbols (e.g., extra dashes and additional inline status code details) that may affect readability. Consider simplifying or reformatting the table header to improve clarity and consistency with the rest of the document.
1636-1645: Filter Service Overview and Grammar Correction
The overview for the Filter service effectively explains its role in providing insert, update, upsert, and search functionality for the Vald Filter Gateway. One minor issue to address: the sentence “Vald Filter Gateway forward user request…” should use “forwards” to maintain correct grammar.
1676-1682: Flush Service Overview Clarity
The new overview for the Flush service succinctly indicates that it is responsible for removing all indexed and uncommitted vectors in thevald-agent. For enhanced clarity, it might be helpful to briefly explain what “uncommitted” means in this context, especially for readers who may not be familiar with the term.
1693-1696: Index Manager Service Overview Improvement
The overview for the index manager service is brief. Consider rephrasing the existing text to something along the lines of “The index manager service is responsible for managing and providing information on indices within the system.” This would add clarity and align the style with the other service overviews.
1714-1717: Insert Service Overview and Typo Correction
The Insert service overview clearly states its purpose of inserting new vectors into thevald-agent. However, note that in the table that follows, the description mistakenly uses “Inset RPC” instead of “Insert RPC.” Please correct this typographical error to maintain consistency in terminology.
1752-1755: Object Service Overview Enhancement
The new overview for the Object service explains that it is responsible for retrieving inserted vectors and verifying their presence in the system. The phrase “checking whether vectors are inserted” can be improved for clarity. Consider rephrasing it to “verifying the successful insertion of vectors” so the responsibility is unmistakably conveyed.
1776-1777: Remove Service Overview Review
The overview for the Remove service is concise and clearly indicates its purpose in removing indexed vectors from thevald-agent. It might be beneficial to mention whether this service handles single removals, batch removals, or both; however, if that detail is fully covered in the following table, this note can be considered optional.
1822-1824: Search Service Overview Clarity
The overview for the Search service briefly states its responsibility for finding vectors similar to a given request vector. To improve clarity, consider specifying that the service searches for vectors that most closely match the provided input, reinforcing the intent behind the search functionality.
1906-1908: Update Service Overview Rewording
The current description “Update Service updates to new vector from inserted vector” is ambiguous. A clearer alternative might be “The Update Service is responsible for updating an existing vector with new data within thevald-agent.” This rewording would help users better understand the service’s functionality.apis/swagger/v1/vald/filter.swagger.json (3)
17-17: Clear and Informative InsertObject SummaryThe updated summary for the
/insert/objectendpoint is detailed and clearly outlines the purpose, status codes, and troubleshooting note. This structured format improves readability and developer understanding.
113-113: Detailed StreamSearchObject RPC OverviewThe summary for the
/search/object/multipleendpoint now clarifies the bidirectional streaming behavior and includes a comprehensive status code table. Verify that the HTML<br>element (encoded as\u003cbr\u003e) renders as intended in your documentation viewers.
177-178: Enhanced MultiUpdateObject RPC InformationThe new summary and accompanying description for the
/update/object/multipleendpoint now include a warning regarding gRPC message size limitations along with a status code table. This is a valuable addition; just ensure the note styling remains consistent across endpoints.apis/swagger/v1/vald/object.swagger.json (1)
47-47: Placeholder Summary for Object ListThe new summary for the
/object/listendpoint introduces the structured format ("Overview", "Status Code", "Troubleshooting") even though the status code and troubleshooting sections are marked TODO. Ensure these placeholders are filled in later for consistency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (31)
apis/grpc/v1/agent/core/agent.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/agent/sidecar/sidecar.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/discoverer/discoverer.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/egress/egress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/ingress/ingress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/meta/meta.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/payload/payload.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/rpc/errdetails/error_details.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goexample/client/go.sumis excluded by!**/*.sumgo.sumis excluded by!**/*.sumrust/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (107)
.gitfiles(15 hunks).github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/security_issue_report.md(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks).github/workflows/_docker-image.yaml(1 hunks).github/workflows/_release-pr.yaml(1 hunks).github/workflows/build-binaries.yaml(1 hunks).github/workflows/build-protobuf.yaml(1 hunks).github/workflows/chatops.yaml(5 hunks).github/workflows/codeql-analysis.yml(2 hunks).github/workflows/coverage.yaml(1 hunks).github/workflows/e2e-chaos.yaml(4 hunks).github/workflows/e2e-code-bench-agent.yaml(2 hunks).github/workflows/e2e-max-dim.yaml(1 hunks).github/workflows/e2e-profiling.yaml(1 hunks).github/workflows/e2e.yaml(8 hunks).github/workflows/format.yaml(3 hunks).github/workflows/fossa.yaml(1 hunks).github/workflows/helm-lint.yaml(3 hunks).github/workflows/helm.yaml(2 hunks).github/workflows/reviewdog-k8s.yaml(3 hunks).github/workflows/reviewdog.yaml(2 hunks).github/workflows/test-hack.yaml(1 hunks).github/workflows/unit-test-rust.yaml(1 hunks).github/workflows/unit-test.yaml(3 hunks).github/workflows/update-deps.yaml(1 hunks)Makefile(8 hunks)Makefile.d/e2e.mk(1 hunks)Makefile.d/functions.mk(1 hunks)Makefile.d/minikube.mk(1 hunks)Makefile.d/tools.mk(2 hunks)apis/docs/v1/docs.md(10 hunks)apis/swagger/v1/mirror/mirror.swagger.json(1 hunks)apis/swagger/v1/vald/filter.swagger.json(8 hunks)apis/swagger/v1/vald/flush.swagger.json(1 hunks)apis/swagger/v1/vald/index.swagger.json(5 hunks)apis/swagger/v1/vald/insert.swagger.json(2 hunks)apis/swagger/v1/vald/object.swagger.json(4 hunks)apis/swagger/v1/vald/remove.swagger.json(3 hunks)apis/swagger/v1/vald/search.swagger.json(8 hunks)apis/swagger/v1/vald/update.swagger.json(3 hunks)apis/swagger/v1/vald/upsert.swagger.json(2 hunks)charts/vald/values/dev.yaml(1 hunks)cmd/index/job/deletion/main_test.go(1 hunks)dockers/agent/core/agent/Dockerfile(1 hunks)dockers/agent/core/faiss/Dockerfile(1 hunks)dockers/agent/core/ngt/Dockerfile(1 hunks)dockers/agent/sidecar/Dockerfile(1 hunks)dockers/binfmt/Dockerfile(1 hunks)dockers/buildbase/Dockerfile(1 hunks)dockers/buildkit/Dockerfile(1 hunks)dockers/buildkit/syft/scanner/Dockerfile(1 hunks)dockers/ci/base/Dockerfile(1 hunks)dockers/dev/Dockerfile(1 hunks)dockers/discoverer/k8s/Dockerfile(1 hunks)dockers/example/client/Dockerfile(1 hunks)dockers/gateway/filter/Dockerfile(1 hunks)dockers/gateway/lb/Dockerfile(1 hunks)dockers/gateway/mirror/Dockerfile(1 hunks)dockers/index/job/correction/Dockerfile(1 hunks)dockers/index/job/creation/Dockerfile(1 hunks)dockers/index/job/deletion/Dockerfile(1 hunks)dockers/index/job/readreplica/rotate/Dockerfile(1 hunks)dockers/index/job/save/Dockerfile(1 hunks)dockers/index/operator/Dockerfile(1 hunks)dockers/manager/index/Dockerfile(1 hunks)dockers/operator/helm/Dockerfile(1 hunks)dockers/tools/benchmark/job/Dockerfile(1 hunks)dockers/tools/benchmark/operator/Dockerfile(1 hunks)dockers/tools/cli/loadtest/Dockerfile(1 hunks)example/client/go.mod(2 hunks)example/client/go.mod.default(1 hunks)go.mod(14 hunks)hack/go.mod.default(4 hunks)internal/backoff/backoff.go(2 hunks)internal/backoff/backoff_test.go(1 hunks)internal/backoff/option.go(0 hunks)internal/backoff/option_test.go(0 hunks)internal/client/v1/client/discoverer/discover.go(1 hunks)internal/client/v1/client/discoverer/discover_test.go(5 hunks)internal/config/benchmark_test.go(4 hunks)internal/config/config.go(2 hunks)internal/config/config_test.go(1 hunks)internal/config/grpc.go(1 hunks)internal/config/index_deleter_test.go(1 hunks)internal/core/algorithm/usearch/usearch_test.go(16 hunks)internal/db/nosql/cassandra/option_test.go(8 hunks)internal/errors/errors.go(2 hunks)internal/errors/errors_test.go(1 hunks)internal/errors/k8s.go(1 hunks)internal/errors/params.go(1 hunks)internal/file/file.go(3 hunks)internal/file/file_test.go(1 hunks)internal/info/info_test.go(17 hunks)internal/iter/iter.go(1 hunks)internal/net/dialer_test.go(1 hunks)internal/net/grpc/client.go(13 hunks)internal/net/grpc/errdetails/errdetails.go(6 hunks)internal/net/grpc/metadata_test.go(1 hunks)internal/net/grpc/option.go(1 hunks)internal/net/grpc/option_test.go(46 hunks)internal/net/grpc/pool/option.go(1 hunks)internal/net/grpc/pool/option_test.go(6 hunks)internal/net/grpc/pool/pool.go(6 hunks)internal/net/grpc/pool/pool_bench_test.go(2 hunks)internal/net/grpc/server_test.go(2 hunks)internal/net/grpc/status/status.go(1 hunks)
⛔ Files not processed due to max files limit (46)
- internal/net/grpc/status/status_test.go
- internal/net/grpc/stream.go
- internal/net/grpc/stream_test.go
- internal/net/http/client/client.go
- internal/net/http/client/client_test.go
- internal/net/http/client/option_test.go
- internal/net/net.go
- internal/net/net_test.go
- internal/net/quic/conn_test.go
- internal/net/quic/listener_test.go
- internal/params/option.go
- internal/params/option_test.go
- internal/params/params.go
- internal/params/params_test.go
- internal/rand/rand.go
- internal/runner/runner.go
- internal/servers/server/option_test.go
- internal/servers/server/server.go
- internal/servers/servers.go
- internal/sync/errgroup/group.go
- internal/sync/errgroup/group_test.go
- internal/test/data/vector/gen.go
- internal/test/data/vector/noise/noise.go
- internal/test/data/vector/noise/noise_test.go
- internal/test/data/vector/noise/option.go
- internal/test/data/vector/noise/option_test.go
- internal/test/mock/server_stream.go
- internal/timeutil/time.go
- internal/timeutil/time_test.go
- k8s/agent/ngt/configmap.yaml
- k8s/discoverer/deployment.yaml
- k8s/gateway/gateway/lb/deployment.yaml
- k8s/gateway/gateway/mirror/deployment.yaml
- k8s/index/operator/deployment.yaml
- k8s/manager/index/deployment.yaml
- pkg/agent/core/faiss/service/faiss.go
- pkg/agent/core/ngt/service/ngt.go
- pkg/agent/core/ngt/service/ngt_test.go
- pkg/agent/core/ngt/service/option_test.go
- pkg/discoverer/k8s/service/discover_test.go
- pkg/gateway/lb/handler/grpc/aggregation_test.go
- pkg/gateway/lb/handler/grpc/handler_test.go
- pkg/gateway/mirror/service/mirror.go
- pkg/index/job/deletion/config/config_test.go
- pkg/index/job/deletion/service/deleter_test.go
- pkg/index/job/deletion/service/options_test.go
💤 Files with no reviewable changes (2)
- internal/backoff/option_test.go
- internal/backoff/option.go
🧰 Additional context used
🧠 Learnings (1)
.gitfiles (1)
Learnt from: datelier
PR: vdaas/vald#2807
File: rust/bin/agent/src/handler/object.rs:36-38
Timestamp: 2025-04-01T12:29:37.305Z
Learning: In Rust code for Vald handlers, avoid using unwrap() on Option types. Instead, handle None values explicitly by returning appropriate error statuses to maintain robustness.
🧬 Code Definitions (4)
internal/net/grpc/status/status.go (2)
internal/errors/errors.go (1)
Is(163-168)internal/net/grpc/codes/codes.go (1)
Code(22-22)
internal/config/grpc.go (1)
internal/net/grpc/option.go (1)
WithOldConnCloseDelay(656-663)
internal/net/grpc/client.go (3)
internal/errors/errors.go (3)
IsNot(182-192)IsAny(170-180)Is(163-168)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/net/grpc/status/status.go (3)
Error(125-127)FromError(185-257)Is(48-50)
internal/net/grpc/pool/pool.go (5)
internal/net/grpc/client.go (2)
ClientConn(50-50)DialOption(49-49)internal/errors/errors.go (2)
Is(163-168)IsNot(182-192)internal/net/grpc/status/status.go (1)
Is(48-50)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/net/grpc/option.go (1)
Option(41-41)
🪛 GitHub Actions: Run unit tests
Makefile
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
🔇 Additional comments (186)
.github/ISSUE_TEMPLATE/bug_report.md (1)
25-32: Ensure Consistent Version Updates in Bug Report Template.
The version numbers for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss have been updated appropriately. Please verify that these values are aligned with the rest of the documentation and any dependency references for consistency across the project..github/PULL_REQUEST_TEMPLATE.md (1)
18-25: Verify Version Consistency in PR Template.
The updated version numbers in the "Versions" section correctly reflect the new releases. Confirm that these changes are in line with the updates in the bug report and security issue templates to maintain overall consistency..github/ISSUE_TEMPLATE/security_issue_report.md (1)
19-26: Validate Security Template Version Updates.
The modifications properly update the versions for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss. Ensure these versions match those in the other templates and any internal configuration to avoid any discrepancies in reported environments.dockers/buildbase/Dockerfile (1)
19-21: Minimal Formatting Update.
A newline was added at the end of the file (line 20 now contains the base image directive). This change is purely stylistic and does not affect functionality.dockers/binfmt/Dockerfile (1)
19-21: Trivial Newline Addition.
The only modification is the addition of a newline at the end of the file. The base image declaration remains unchanged and is correct.dockers/buildkit/Dockerfile (1)
19-21: Minimal Formatting Update.
A newline character was added at the end of the file, with the base image declaration (FROM moby/buildkit:master AS builder) remaining unchanged. This is a benign change.example/client/go.mod.default (1)
3-3: Go Version Update.
The Go version has been updated to1.24.2. Please verify that all dependencies and build processes are compatible with this version.dockers/buildkit/syft/scanner/Dockerfile (1)
20-20: Formatting Update: Newline AdditionThe addition of a newline at the end of the file is a formatting improvement. There are no changes to the base image or build steps.
dockers/tools/benchmark/job/Dockerfile (1)
96-96: ENTRYPOINT FormattingThe
ENTRYPOINT ["/usr/bin/job"]directive at line 96 is identical to the previous version; this change is purely a formatting update (removal/addition of a newline) with no impact on container behavior.dockers/dev/Dockerfile (1)
143-144: Security Warning: Final USERThe Dockerfile’s final
USERis set toroot:rootat line 143. This has previously been flagged by hadolint, as running containers as root may pose security risks.dockers/gateway/mirror/Dockerfile (1)
89-89: ENTRYPOINT Directive UnchangedThe change to the
ENTRYPOINT ["/usr/bin/mirror"]directive (line 89) is a simple formatting update with no alteration in execution or functionality.dockers/example/client/Dockerfile (1)
95-95: Consistent ENTRYPOINT FormattingThe updated
ENTRYPOINT ["/usr/bin/client"]at line 95 reflects only a newline/formatting change without affecting the container’s startup command.dockers/ci/base/Dockerfile (1)
130-130: Consistent ENTRYPOINT Formatting
The updatedENTRYPOINT ["/bin/bash"]at line 130 is a quality formatting change that standardizes the Dockerfile across the repository. No functional change is observed, so this update is approved.dockers/tools/cli/loadtest/Dockerfile (1)
96-96: Standardize ENTRYPOINT Directive
The change adding the newline withENTRYPOINT ["/usr/bin/loadtest"]is purely a formatting update. This modification aligns the file with the repository-wide Dockerfile standards without impacting functionality.dockers/index/job/save/Dockerfile (1)
89-89: ENTRYPOINT Formatting Update
The modification toENTRYPOINT ["/usr/bin/index-save"](ensuring no extraneous newline characters and a clean directive) is a simple formatting standardization. No functional impact is seen, so the change is approved.dockers/manager/index/Dockerfile (1)
89-89: ENTRYPOINT Directive Consistency
The updatedENTRYPOINT ["/usr/bin/index"]at line 89 reflects a formatting alignment with the rest of the codebase. This is nonfunctional and improves consistency—approved as is.dockers/index/operator/Dockerfile (1)
89-89: Clean and Consistent ENTRYPOINT
The change toENTRYPOINT ["/usr/bin/index-operator"]simply refines the formatting by removing unnecessary newline discrepancies. This update helps maintain consistency and is functionally equivalent to the previous version.dockers/index/job/deletion/Dockerfile (1)
89-90: File formatting improvement: Added newline at the end of file.This change adds a proper newline at the end of the file, which follows the POSIX standard and is considered good practice in file formatting.
dockers/tools/benchmark/operator/Dockerfile (1)
89-90: File formatting improvement: Added newline at the end of file.This change adds a proper newline at the end of the file, which follows the POSIX standard and is considered good practice in file formatting.
dockers/gateway/filter/Dockerfile (1)
89-90: File formatting improvement: Added newline at the end of file.This change adds a proper newline at the end of the file, which follows the POSIX standard and is considered good practice in file formatting.
Makefile.d/tools.mk (2)
215-217: Enhanced CMake configuration with policy version minimum for zlib.Adding the CMake policy version minimum parameter is a best practice that helps ensure consistent build behavior across different CMake versions.
244-246: Enhanced CMake configuration with policy version minimum for hdf5.Adding the CMake policy version minimum parameter is a best practice that helps ensure consistent build behavior across different CMake versions.
dockers/gateway/lb/Dockerfile (1)
89-90: Consistent formatting changeThe modification adds a proper newline at the end of the file, which is a good practice for text files in Unix/Linux environments. This change aligns with similar updates across other Dockerfiles in the repository.
dockers/index/job/correction/Dockerfile (1)
89-90: Consistent formatting changeThe modification adds a proper newline at the end of the file, which is a good practice for text files in Unix/Linux environments. This change aligns with similar updates across other Dockerfiles in the repository.
dockers/index/job/readreplica/rotate/Dockerfile (1)
89-90: Consistent formatting changeThe modification adds a proper newline at the end of the file, which is a good practice for text files in Unix/Linux environments. This change aligns with similar updates across other Dockerfiles in the repository.
dockers/index/job/creation/Dockerfile (1)
89-90: Consistent formatting changeThe modification adds a proper newline at the end of the file, which is a good practice for text files in Unix/Linux environments. This change aligns with similar updates across other Dockerfiles in the repository.
Makefile.d/minikube.mk (1)
28-29: Explicit Docker driver configuration improves reproducibilityThe changes explicitly configure and use Docker as the driver for Minikube, which improves the reproducibility of the development environment. This is beneficial for the new E2E testing framework mentioned in the PR objectives, as it ensures consistent behavior across different development environments.
internal/config/benchmark_test.go (2)
22-22: Addition of Meta field enhances configuration options for benchmark targetsThe addition of the
Meta map[string]stringfield to thefieldsstruct allows for storing additional metadata with benchmark targets, which aligns with the E2E testing framework enhancements mentioned in the PR objectives.
49-49: Properly initialized Meta field in test cases and implementationThe Meta field is consistently initialized as
nilin the test cases and properly assigned to the BenchmarkTarget instance. This ensures backward compatibility with existing tests while supporting the new metadata capabilities.Also applies to: 70-70, 103-103
internal/config/grpc.go (1)
186-186: Function name update from WithOldConnCloseDuration to WithOldConnCloseDelayThis change updates the function call to match the renamed API in the internal/net/grpc package, maintaining consistent naming across the codebase. The functionality remains the same, but the name better reflects that it's a delay before closing old connections.
apis/swagger/v1/mirror/mirror.swagger.json (1)
17-17: Improved API documentation with detailed overview and status codesThe enhanced summary for the Register RPC provides much more comprehensive documentation, including:
- A clear overview explaining that the RPC registers other Vald Mirror Gateway targets
- A well-formatted status code table that explains possible response codes
This documentation improvement will help developers understand the API behavior and expected responses, supporting better test development for the new E2E framework.
internal/core/algorithm/usearch/usearch_test.go (1)
670-670: Consistent change of mutex initialization to nil in test stubs.The changes uniformly update the
mufield initialization fromsync.RWMutex{}tonilacross all commented-out test case stubs. This approach is more consistent with how synchronization would be handled in the actual implementation.Also applies to: 698-698, 802-802, 832-832, 932-932, 960-960, 1065-1065, 1097-1097, 1200-1200, 1231-1231, 1340-1340, 1372-1372, 1475-1475, 1506-1506, 1602-1602, 1630-1630
.github/workflows/_docker-image.yaml (1)
73-83:✅ Verification successful
Improved Docker registry authentication steps.
The added steps properly configure authentication for both DockerHub and GitHub Container Registry using the recommended
docker/login-action@v3action with appropriate secrets. This ensures the workflow can push images to both registries.
🏁 Script executed:
#!/bin/bash # Verify that the login-action is the latest version curl -s https://api.github.com/repos/docker/login-action/releases/latest | grep '"tag_name":' | cut -d'"' -f4Length of output: 118
Verified and Approved: Docker Registry Authentication Setup Is Correct
The workflow now correctly configures DockerHub and GitHub Container Registry authentication using the recommended
docker/login-action@v3. Our verification confirmed that this version tag currently references the latest release (v3.4.0), ensuring robust and up-to-date authentication steps. No further changes are needed in these lines.
- Confirmed usage of proper secrets for both registries.
- Verified that
docker/login-action@v3correctly points to v3.4.0 via the latest release check.internal/db/nosql/cassandra/option_test.go (1)
538-538: Error handling cleanup: Simplified error messages in duration-related tests.The changes simplify error handling in multiple test functions by using direct error messages from time parsing failures instead of combining them with additional context. This improves error message clarity while maintaining the same test validation logic.
Also applies to: 1524-1525, 1616-1617, 1708-1709, 1875-1876, 2980-2981, 3070-3071, 3925-3926
internal/info/info_test.go (1)
341-342: Added fieldvaldReplacerto structfieldsThe new field
valdReplacerof type*strings.Replacerhas been added to thefieldsstruct. This appears to be necessary for supporting the implementation in the main code, but be sure to include this field in any new test cases you might create in the future.internal/errors/errors.go (3)
86-88: Well-implemented error generator function for unimplemented featuresThe new
ErrUnimplementedfunction creates a clear error message for unimplemented features. This is a good addition that will help provide explicit information to users when they encounter unimplemented functionality.
170-180: Good implementation of theIsAnyerror matching functionThe
IsAnyfunction provides a convenient way to check if an error matches any of the provided target errors. The implementation correctly handles nil errors and empty targets, which is good defensive programming.
182-192: Well-structuredIsNotfunction for error non-matchingThe
IsNotfunction complementsIsAnyby checking if an error doesn't match any specified targets. The implementation correctly handles edge cases, including whenerris nil or when no targets are provided.internal/file/file.go (3)
259-259: Improved error handling witherrors.IsNotUsing the new
errors.IsNotfunction makes the code more concise and readable while maintaining the same functionality as the previous conditionerr != nil && !errors.Is(err, io.EOF).
374-391: Well-implementedAbsolutePathfunctionThe new
AbsolutePathfunction correctly handles various path scenarios:
- Empty paths
- Converting relative paths to absolute paths
- Cleaning paths to remove redundancies
This is a good abstraction that centralizes path normalization logic, making the code more maintainable.
564-564: Simplified path handling inJoinUsing the new
AbsolutePathfunction inJoinreduces code duplication and improves maintainability by centralizing the logic for converting paths to their absolute form.apis/swagger/v1/vald/index.swagger.json (5)
17-17: Documentation enhancement approved.
Prepending"Overview\n"clarifies endpoint purpose.
38-38: Documentation enhancement approved.
The updated summary improves clarity and consistency across endpoints.
59-59: Documentation enhancement approved.
This subtle improvement ensures consistent summary formatting.
80-80: Documentation enhancement approved.
Including"Overview\n"maintains a uniform approach in describing endpoints.
101-101: Documentation enhancement approved.
Adding"Overview\n"aligns the endpoint summary with the newly adopted style.internal/config/config.go (3)
99-115: Logic for reading environment variables from files looks good.
If the file read fails (line 109), it silently returns an empty string. Ensure this is the desired fallback. Otherwise, consider logging or handling the error differently.
120-125: Bulk environment variable expansion is well-structured.
Looping through slice values and applyingGetActualValueensures consistency.
128-130: No issues with prefix/suffix check.
Generic usage ofT ~stringis concise and readable.internal/iter/iter.go (1)
1-153: Iterator abstraction looks well-designed.
- The context-aware iteration is a nice touch to handle cancellation.
- Verify concurrency requirements; if multiple goroutines share this iterator, additional safeguards may be needed.
Overall, it’s a neat pattern for cycling through slices.internal/net/grpc/pool/option.go (6)
37-38: Function name change to improve clarity.The renamed function
WithOldConnCloseDelayis more descriptive than the previousWithOldConnCloseDurationas it better represents the purpose of the setting.
42-54: Improved error handling in WithAddr function.The updated implementation now properly attempts to split the address into host and port components, with a fallback to using the entire address as the host when splitting fails.
93-97: Improved parameter naming in WithResolveDNS function.Renamed parameter from
flgtoenablefor better self-documentation. The function's purpose is also clarified with the added comment.
109-116: Updated poolSize storage in WithSize function.The variable assignment has been changed from
p.size.Store(size)top.poolSize.Store(size), likely matching a renamed field in the pool struct.
127-137: Simplified conditional logic in WithDialTimeout function.The error handling has been streamlined by directly assigning the parsed time to the respective field when no error occurs.
139-149: Renamed WithOldConnCloseDelay function with improved implementation.Function has been renamed from
WithOldConnCloseDurationtoWithOldConnCloseDelaywith a clearer comment and improved implementation for error handling. This matches the change in the default options listed earlier.Makefile (9)
163-164: Updated optimization flags in LDFLAGS.Changed from
-Ofastto-O3and added-ffast-math. This is a more controlled optimization approach as-O3provides high optimization without some of the potential precision trade-offs that-Ofastmight introduce.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
167-169: Added math library to HDF5_LDFLAGS and simplified TEST_LDFLAGS.Added
-lmto HDF5_LDFLAGS to explicitly link the math library, and simplified TEST_LDFLAGS to use the centralized CGO_LDFLAGS variable rather than concatenating multiple flags.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
355-356: Added E2E configuration variables.These new variables support the enhanced E2E testing framework mentioned in the PR objectives, making the testing configuration more flexible.
🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
470-476: Improved.gitfileshandling in the files target.The updated implementation now properly handles both creation and updating of the
.gitfilesfile, with better file operation logic.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
552-563: Enhanced Go formatting workflow.The improved formatting process now:
- Uses
.gitfilesinstead of find commands for better efficiency- Provides informative output about which files are being formatted
- Processes files in parallel with
-P$(CORES)🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
571-582: Similar improvements to Go test file formatting.Applied the same enhancements to the test file formatting process, maintaining consistency with the main Go formatting target.
🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
702-703: Added CMake policy version compatibility.Added
-DCMAKE_POLICY_VERSION_MINIMUM=$(CMAKE_VERSION)to ensure compatibility with the specified CMake version during NGT installation.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
724-725: Added CMake policy version for Faiss installation.Consistently applied the same CMake policy version setting to Faiss installation as was done for NGT.
🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
748-749: Added CMake policy version for usearch installation.Consistently applied the same CMake policy version setting to usearch installation as was done for NGT and Faiss.
🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
.gitfiles (10)
126-126: New workflow for Rust unit tests added.This workflow will help maintain test coverage for the Rust components of the Vald project, which is important for the project's stability.
161-177: New API documentation generation infrastructure.These files provide a structured way to generate API documentation, which will help keep documentation in sync with code changes. The templates and markdown files cover key API operations like filtering, flushing, indexing, and searching.
488-488: QBG algorithm configuration sample added.This sample configuration file will help users understand how to configure the QBG algorithm implementation.
1051-1051: New error handling for parameters.This addition enhances error handling capabilities specifically for parameter-related errors, which aligns with the PR's focus on improved maintainability.
1088-1088: New iterator abstraction package.The introduction of this package provides a generic iterator abstraction that will likely be used by the new E2E testing framework, enhancing code reusability across the project.
1274-1276: QUIC protocol test coverage added.These tests improve coverage for the QUIC protocol implementation, ensuring better reliability of the networking components.
Note: Previous linting reported "quic" as an unknown word, but this is a valid technical term referring to the QUIC (Quick UDP Internet Connections) protocol. Consider adding "quic" to your cspell dictionary to avoid false positives.
1407-1410: Vector noise testing utilities added.These utilities will help test vector operations with controlled noise, which is essential for reliable vector similarity search testing.
1986-1990: Rust QBG algorithm implementation.This adds a Quantization-Based Graph (QBG) algorithm implementation in Rust, expanding the available vector search algorithms in the project.
Ensure that the Rust implementation follows the guidelines mentioned in the retrieved learning about avoiding
unwrap()on Option types and handling None values explicitly for better robustness.
2035-2055: New E2E testing framework introduced.This is the core feature of the PR, introducing a comprehensive end-to-end testing framework with improved maintainability. The framework includes:
- Configurable operations through YAML assets
- Kubernetes integration and port forwarding
- Dataset handling utilities
- Various test strategies for different API operations
This structured approach will significantly enhance the project's testing capabilities and ensure better reliability.
2067-2067: K3D version pinning added.Adding version pinning for K3D will ensure consistent behavior in CI/CD pipelines and local development environments when using Kubernetes clusters.
hack/go.mod.default (4)
3-3: Go version updated to 1.24.2.The Go version has been upgraded from 1.24.0 to 1.24.2, which includes bug fixes and security improvements. This aligns with the PR objectives to maintain the codebase with updated dependencies.
16-16: Cloud storage dependency updated to use upgrade directive.The cloud.google.com/go/storage dependency now uses the upgrade directive rather than a fixed version, which aligns with the pattern used for other Google Cloud dependencies.
332-341: Kubernetes dependencies updated to v0.32.3.All Kubernetes-related dependencies have been updated from v0.32.0 to v0.32.3, which includes bug fixes and improvements. This is a minor version update that maintains API compatibility.
344-347: Controller runtime and structured-merge-diff packages updated.The following packages have been updated:
- sigs.k8s.io/controller-runtime from v0.19.3 to v0.20.4
- sigs.k8s.io/structured-merge-diff/v4 from v4.5.0 to v4.6.0
These updates are consistent with the Kubernetes version update and support the E2E testing framework enhancements mentioned in the PR objectives.
example/client/go.mod (3)
3-3: Go version updated to 1.24.2.The Go version has been upgraded from 1.24.0 to 1.24.2, maintaining consistency with the main module.
10-18: Multiple security-related dependencies updated.Several security-sensitive dependencies have been updated to newer versions:
- sftp package updated to v1.13.9
- crypto package updated to v0.36.0
- net package updated to v0.38.0
- text package updated to v0.23.0
- Google's protobuf, gRPC, and genproto packages updated to their latest versions
These updates address potential security vulnerabilities and provide bug fixes.
28-28: Required and indirect dependencies synchronized with newer versions.The gRPC dependency in the require section has been updated to v1.71.0, and indirect dependencies have been updated to compatible versions. This ensures that all dependencies work together correctly with the updated direct dependencies.
Also applies to: 36-41
go.mod (6)
3-3: Go version updated to 1.24.2.The Go version has been upgraded from 1.24.0 to 1.24.2, which includes bug fixes and security improvements.
6-16: Google Cloud dependencies updated to latest versions.Multiple Google Cloud dependencies have been updated to their latest versions, including:
- cloud.google.com/go from v0.118.2 to v0.120.0
- cloud.google.com/go/bigquery from v1.66.2 to v1.67.0
- cloud.google.com/go/compute from v1.33.0 to v1.36.0
- cloud.google.com/go/storage from v1.47.0 to v1.51.0
These updates ensure compatibility with the latest Google Cloud APIs and include bug fixes and performance improvements.
332-341: Kubernetes dependencies updated to v0.32.3.All Kubernetes-related dependencies have been updated from their previous versions to v0.32.3, ensuring consistency across all k8s.io packages. This update supports the enhanced E2E testing framework mentioned in the PR objectives.
344-347: Controller runtime and structured-merge-diff packages updated.The following Kubernetes-related packages have been updated:
- sigs.k8s.io/controller-runtime from previous version to v0.20.4
- sigs.k8s.io/structured-merge-diff/v4 to v4.6.0
These updates align with the Kubernetes version updates and support the new E2E testing framework.
426-543: Indirect dependencies updated to compatible versions.Numerous indirect dependencies have been updated to versions that are compatible with the direct dependencies. These updates ensure the entire dependency graph remains consistent and works correctly with the updated Go version and direct dependencies.
352-422:✅ Verification successful
Required dependencies updated, with some using placeholder versions.
Multiple direct dependencies have been updated to newer versions, but several dependencies are now using placeholder versions (v0.0.0-00010101000000-000000000000). These placeholders indicate that the specific dependency version is managed through the replace directives, ensuring compatibility with the rest of the project.
However, it's worth noting that using these placeholder versions makes the module file less readable and might cause confusion for contributors unfamiliar with this pattern.
🏁 Script executed:
#!/bin/bash # Check if any of the placeholder versions cause issues with go mod tidy echo "Checking for potential dependency resolution issues..." go mod tidy -v 2>&1 | grep -i "inconsistent"Length of output: 158
Dependency update verification complete – no issues found with placeholder versions.
The updated dependencies in the
go.modfile have been verified usinggo mod tidy; no inconsistency or resolution issues were detected. As noted, several dependencies now show placeholder versions (v0.0.0-00010101000000-000000000000), which indicates that their precise versions are managed viareplacedirectives. While this pattern is technically sound, it can detract from immediate readability and might confuse contributors who are not familiar with this approach. Consider adding a brief inline comment or updating the project’s documentation to clarify this version management strategy if you expect new team members to work on the module file.
- Verified dependency resolution with
go mod tidy(no “inconsistent” errors were reported).- Placeholder versions are being managed via
replacedirectives; no technical issues detected.- Suggestion: Clarify the use of placeholders for improved readability for future contributors.
internal/net/grpc/option_test.go (1)
532-3344: Well-structured reorganization of test function names and parameters.The changes refactor the test functions in
option_test.goto better align the test names with the functions they are testing. The parameter types have been updated to match the expected parameters of each corresponding function, making the test structure more accurate and maintainable.Notable changes include:
- Renamed test functions to match their corresponding package functions (e.g.,
TestWithDialOptions→TestWithBackoffMaxDelay)- Updated parameter types to match the expected function signatures
- Added new test functions for additional gRPC options
- Reordered tests to maintain a logical grouping
dockers/operator/helm/Dockerfile (1)
110-110: Newline added at end of fileThe addition of a newline at the end of the file follows Unix text file conventions and helps prevent issues with certain tools that expect files to end with a newline character.
dockers/agent/core/ngt/Dockerfile (1)
98-98: Consistent file formatting appliedThe addition of a newline at the end of the file follows Unix text file conventions and ensures consistency with other Dockerfiles in the project.
dockers/discoverer/k8s/Dockerfile (1)
89-89: Consistent formatting applied to ENTRYPOINT directiveThe newline addition at the end of the file maintains consistency across all Dockerfiles in the project and follows standard Unix text file conventions.
.github/workflows/fossa.yaml (1)
39-41: Security enhancement: Added container registry authenticationAdded credentials for accessing the container registry using repository secrets, which improves security by preventing anonymous image pulls and potential rate limiting issues.
Makefile.d/e2e.mk (1)
22-25: Added new E2E v2 testing targetThis new target implements the strategic testing framework mentioned in the PR objectives. It calls a new function
run-v2-e2e-crud-testthat runs tests from the V2 framework with a specific test matcher.The addition aligns perfectly with the PR objective to add "E2E test V2 Strategic testing framework for more maintainability."
dockers/agent/sidecar/Dockerfile (1)
87-89: ENTRYPOINT formatting update in sidecar Dockerfile.
The new ENTRYPOINT instruction is identical to the previous one, so there is no functional change. This update mainly improves consistency and formatting. Consider ensuring a trailing newline if your style guidelines require it..github/workflows/build-binaries.yaml (1)
34-36: Added container credentials in build-binaries workflow.
The addition of thecredentialssection withusernameandpasswordsourced from secrets enhances the security for accessing the container image. This change is consistent with improvements seen in other workflow files.dockers/agent/core/agent/Dockerfile (1)
96-98: Standardizing the ENTRYPOINT in the agent Dockerfile.
The update to the ENTRYPOINT instruction is a formatting change aimed at consistency across Dockerfiles. There is no impact on functionality.dockers/agent/core/faiss/Dockerfile (1)
98-100: Consistent ENTRYPOINT update in the FAISS Dockerfile.
This change standardizes the ENTRYPOINT instruction by ensuring formatting consistency. No functional modification has occurred..github/workflows/coverage.yaml (1)
42-44: Enhanced container authentication in coverage workflow.
The introduction of a credentials section for the container, which uses secrets for authentication, aligns with the security enhancements adopted in other workflow files. This update improves the overall security posture of the CI/CD pipeline.internal/net/grpc/status/status.go (1)
48-50: Good utility function addition.This new utility function provides a cleaner way to check if an error has a specific gRPC status code, making the code more readable compared to directly using
status.Code(err) == codethroughout the codebase..github/workflows/reviewdog.yaml (2)
35-37: Good security practice for container authentication.Adding credentials for container registry access is a good practice to avoid rate limiting and access issues when pulling containers from ghcr.io.
57-59: Good security practice for container authentication.Adding credentials for the go-build job follows the same pattern as the golangci-lint job, ensuring consistent authentication practices across workflow jobs.
.github/workflows/e2e-max-dim.yaml (1)
43-45: Good security practice for container authentication.Adding credentials for container registry access in the e2e workflow ensures consistent authentication practices across the CI/CD pipeline, improving reliability when pulling container images from ghcr.io.
.github/workflows/update-deps.yaml (1)
34-36: Good security practice for container authentication.Adding credentials for the update-deps workflow follows the same authentication pattern as the other workflows, maintaining consistency across the CI/CD pipeline.
.github/workflows/_release-pr.yaml (1)
44-46: Credential configuration added to the container.
The newcredentialssection, assigningusernameandpasswordfrom GitHub secrets, correctly enhances the container’s ability to authenticate. Please verify that the referenced secrets (PACKAGE_USERandPACKAGE_TOKEN) are properly configured in the repository..github/workflows/build-protobuf.yaml (1)
42-45: Credentials integrated into the build container configuration.
The inclusion of thecredentialsblock with the appropriate secret references is consistent with the other workflow updates and should improve secure access. Confirm that the secrets are available in your settings..github/workflows/e2e-code-bench-agent.yaml (2)
60-63: Added credentials for the grpc-sequential container.
The new block assigningusernameandpasswordensures that the grpc-sequential job can authenticate appropriately. Please double-check that the secrets are up-to-date.
90-93: Added credentials for the grpc-stream container.
Similar to the sequential job, the grpc-stream container now includes authentication credentials. Verify that these changes are maintained across similar workflows for consistency.internal/net/grpc/option.go (1)
656-663: Renamed function for improved clarity.
The functionWithOldConnCloseDelayreplaces the previous naming (“Duration”), aligning terminology with its intended behavior. Please ensure that all call sites using the old name are updated to reference this new function name..github/workflows/test-hack.yaml (1)
58-60: Credentials added for the test-hack container.
The newcredentialssection using the GitHub secrets ensures that the container running hack tests can authenticate against required resources. Please confirm that the secrets (PACKAGE_USERandPACKAGE_TOKEN) are properly set up in the project settings..github/workflows/e2e-profiling.yaml (1)
45-47: Added container registry authentication credentials.The addition of container registry credentials using GitHub secrets is a good security practice. This will ensure proper authentication when pulling the container image from your private registry.
.github/workflows/helm-lint.yaml (1)
35-37: Container authentication applied consistently across all jobs.The addition of container registry credentials using GitHub secrets is a good security practice and has been consistently implemented across all jobs in this workflow.
Also applies to: 56-58, 77-79
.github/workflows/unit-test.yaml (1)
54-56: Container authentication applied consistently across all test jobs.The addition of container registry credentials using GitHub secrets is a good security practice and has been consistently implemented across all test jobs in this workflow.
Also applies to: 74-76, 94-96
.github/workflows/e2e-chaos.yaml (1)
47-49: Container authentication applied consistently across all chaos test jobs.The addition of container registry credentials using GitHub secrets is a good security practice and has been consistently implemented across all chaos test jobs in this workflow.
Also applies to: 91-93, 135-137, 179-181
internal/backoff/backoff_test.go (1)
63-63: Changed default error logging behavior in backoff test.The test now expects the default
errLogvalue to befalseinstead oftrue, indicating that error logging is now disabled by default in the backoff mechanism.Please verify that this change aligns with the enhancements to error handling in
internal/errorsmentioned in the PR objectives. Consider whether this change might impact error visibility during troubleshooting in production environments..github/workflows/unit-test-rust.yaml (1)
44-46: Authentication for container registry access added.The addition of credentials for the container registry is a good security practice, ensuring proper authentication when pulling the CI container image from the GitHub Container Registry.
.github/workflows/chatops.yaml (1)
32-34: Authentication added consistently across all ChatOps jobs.The credentials for container registry access have been added consistently to all jobs (label, rebase, gentest, format, and approve), ensuring proper authentication when pulling container images from ghcr.io.
Also applies to: 85-87, 165-167, 281-283, 416-418
.github/workflows/helm.yaml (1)
38-40: Container registry authentication added for Helm workflow jobs.The addition of credentials for the container registry access in both Helm-related jobs ensures proper authentication when pulling container images, consistent with changes in other workflow files.
Also applies to: 83-85
internal/backoff/backoff.go (2)
22-22: Added maps package import.The maps package has been imported to use the Clone function for the metrics map.
244-244:✅ Verification successful
Simplified map cloning with maps.Clone.
The code has been improved by using the standard library's maps.Clone function instead of manually creating and populating a new map, making the code more readable and maintainable.
🏁 Script executed:
#!/bin/bash # Check minimum Go version requirement for maps package grep -rn "go 1\." --include="go.mod" . | head -1Length of output: 84
Action: Approved Simplified Map Cloning
The change correctly replaces manual map cloning with the standard library's
maps.Clone, and our verification confirms that the project's minimum Go version (go 1.24.2) supports this function.
- File:
internal/backoff/backoff.go(Line 244)- Improvement: Simplifies code and improves maintainability by leveraging the standard library.
internal/config/config_test.go (1)
999-1003: Test expectations updated to handle missing files correctly.The test case has been updated to verify the function's behavior when a file doesn't exist. The test name has been changed and the expectations modified to reflect that the function should return an empty result when attempting to access a nonexistent file.
This change aligns with error handling improvements in
internal/errors/params.gowhere a newErrArgumentParserNotFoundvariable was added..github/workflows/e2e.yaml (2)
45-47: Enhanced container security with credential authentication.Adding container registry credentials improves security by authenticating with the GitHub Container Registry using proper secrets instead of relying on anonymous access. This ensures reliable access to the container images, especially important for private or rate-limited repositories.
89-91: Consistent credential configuration applied across all workflow jobs.The same credential configuration has been applied to all container specifications throughout the workflow file. This consistency ensures all jobs have proper authentication to access container images.
Also applies to: 156-158, 204-206, 248-250, 288-290, 325-327, 379-381
Makefile.d/functions.mk (1)
134-154: Added new function for running V2 E2E CRUD tests.This new function
run-v2-e2e-crud-testintroduces support for the new end-to-end testing framework mentioned in the PR objectives. Key improvements include:
- Streamlined test configuration through environment variables
- Support for the new test structure in
tests/v2/e2e/crud- Proper configuration of Go build environment variables
The function complements the existing
run-e2e-crud-testfunction and provides a foundation for the strategic testing framework enhancements described in the PR summary..github/workflows/reviewdog-k8s.yaml (1)
36-38: Enhanced container authentication for CI workflows.Adding container registry credentials to all jobs ensures consistent and secure access to container images. This is part of a broader authentication improvement pattern applied across multiple CI workflow files.
Also applies to: 59-61, 81-83
internal/client/v1/client/discoverer/discover.go (1)
290-290: Code improvement: Consolidated error checkingThe use of
errors.IsNotsimplifies the code by replacing multipleerrors.Isnegation checks with a single function call that can check against multiple error types. This enhances readability while maintaining the same functionality.internal/net/grpc/pool/pool_bench_test.go (1)
120-120: Improved benchmarking methodologyReplacing the traditional
for i := 0; i < b.N; i++loop withb.Loop()aligns with Go's recommended benchmarking practices. This approach allows the testing framework to determine the appropriate number of iterations dynamically, potentially leading to more consistent and reliable benchmark results.Also applies to: 144-144
apis/swagger/v1/vald/flush.swagger.json (1)
17-17: Enhanced API documentationThe expanded summary provides much clearer information about the endpoint's purpose and possible response codes. This improvement:
- Clearly describes that the Flush RPC removes all vectors
- Documents all possible status codes and their meanings in a well-organized table format
This change significantly improves API usability and developer experience.
internal/net/grpc/errdetails/errdetails.go (6)
80-82: Good addition of Details structureThe new
Detailsstructure provides a standardized way to represent multiple error details, improving the consistency of error representation in JSON and YAML output.
93-94: Improved type detection and handlingThe updated code properly handles type extraction by trimming prefixes for both standard and v1 type URLs. The addition of a default case ensures that all message types can be properly marshaled, even those not explicitly listed in the switch statement.
Also applies to: 165-167
168-172: Enhanced error handling and loggingThe improved error handling now includes warning logs when marshaling fails, providing better visibility into serialization issues. This will help with debugging when errors occur during message serialization.
316-318: Updated serialization approachThe change to serialize multiple messages using the new
Detailsstructure ensures consistent JSON formatting when handling multiple error details. This is a good structural improvement that makes the output more predictable.
330-331: Increased flexibility for unknown typesThe addition of a default case in
AnyToErrorDetailfunction significantly improves the robustness of the code. It now attempts to unmarshal any unknown message types using the genericUnmarshalNewmethod, making the error handling more extensible and future-proof.Also applies to: 416-421
424-424: Improved logging in error casesEnhanced warning message that now includes the type name in the log, which provides more context when unmarshaling fails. This kind of detailed logging is valuable for troubleshooting issues.
internal/net/grpc/client.go (13)
173-178: Error handling refactored for improved readabilityReplacing multiple
errors.Iscalls with a singleerrors.IsNotcheck improves code readability and maintainability while preserving the same logical behavior.
261-269: Streamlined error check using IsNotSimilar to the previous change, this consolidates multiple error type checks into a single
errors.IsNotcall, making the code more concise and easier to understand.
299-307: Consistent error handling pattern appliedThe change maintains consistent error handling patterns throughout the codebase by using
errors.IsNotinstead of multipleerrors.Ischecks.
374-382: Continuing the error handling refactoring patternThis change follows the same pattern of replacing multiple individual error checks with a single
errors.IsNotcall, ensuring consistency throughout the client implementation.
480-481: Switch to errors.IsAny for positive error checkingUsing
errors.IsAnyfor checking if an error matches any of the specified types is semantically clearer than the previous approach.
503-504: Consistent use of errors.IsAnyThis change maintains the pattern of using
errors.IsAnyfor checking multiple error types, improving consistency throughout the codebase.
753-764: Multiple error checks consolidated with IsAnyGood refactoring to use
errors.IsAnyfor the complex error condition checking, which makes the code more maintainable while preserving the same logic.
853-865: Consistent error checking patternThe changes here follow the same pattern established throughout the file, using
errors.IsAnyto check for multiple error types in a cleaner way.
888-894: Final application of the same error checking patternThis completes the application of the consistent error handling pattern throughout the RPC client implementation.
983-986: More readable error negationUsing
errors.IsNotinstead of!errors.Isis more readable and consistent with the error handling approach used elsewhere in the file.
994-997: Consistent error checking in disconnect handlingSame improvement as the previous error check, using
errors.IsNotfor better readability and consistency.
1051-1051: Simplified error handling for DisconnectDirectly returning the error from
p.Disconnect(ctx)simplifies the code without changing functionality.
1090-1093: Final application of consistent error check patternThis completes the application of the
errors.IsNotpattern throughout the Close method..github/workflows/format.yaml (3)
36-38: Added container registry authenticationAdding credentials for container access is a security improvement that ensures proper authentication when pulling images.
95-97: Consistent credential configurationThis maintains consistency with the authentication approach used in the format job.
108-109: Enhanced formatting and dependencies checkThe expanded make command adds more comprehensive formatting and dependency checks, including license headers, Go formatting, and Go test formatting. The additional checkout of
./rust/rust-toolchain.tomlsuggests proper handling of Rust components in the project.internal/net/grpc/pool/option_test.go (3)
449-449: Improved parameter naming fromflgtoenableRenaming the parameter from
flgtoenableprovides better clarity about the parameter's purpose and follows better naming conventions. This change makes the code more readable and maintainable.
474-474: Consistently updated variable names in test casesThe parameter renaming from
flgtoenablehas been consistently applied throughout all the test cases and function calls, which maintains code consistency.Also applies to: 493-493, 524-524
872-872: Function name updated for clarity:WithOldConnCloseDurationtoWithOldConnCloseDelayThe function name change from
WithOldConnCloseDurationtoWithOldConnCloseDelaybetter reflects the semantic meaning of the option. "Delay" more accurately describes a waiting period before closing connections compared to "Duration". This change improves API clarity.Also applies to: 949-949
internal/net/grpc/server_test.go (1)
29-29: Added import for gRPC proto encodingThe addition of
_ "google.golang.org/grpc/encoding/proto"as a blank import ensures the proto encoding package is initialized. This is a common pattern for registering encoders/decoders in gRPC..github/workflows/codeql-analysis.yml (3)
46-68: Improved CodeQL workflow with matrix strategyThe workflow has been significantly improved by:
- Using a matrix strategy to analyze multiple languages separately
- Appropriately configuring the runner based on language requirements
- Setting up environment variables to enable experimental features
This approach makes the workflow more maintainable and allows for language-specific configurations.
70-72: Added container credentials for private imageContainer credentials have been properly configured to access the private CI container image from GitHub Packages.
84-88: Updated CodeQL action versions to v3All CodeQL actions have been updated from v2 to v3, which includes:
- The initialization action with language-specific configuration
- The autobuild action with conditional execution for Go
- The analyze action with appropriate categorization
These updates ensure the workflow uses the latest features and improvements in the CodeQL toolchain.
Also applies to: 90-91, 93-95
internal/client/v1/client/discoverer/discover_test.go (1)
132-157: Simplify error handling in concurrency tests
The diff (as summarized by the AI) indicates that the error channel parameter (ech) has been removed from several helper function signatures (such as in dnsDiscovery, discover, updateDiscoveryInfo, etc.) to simplify error handling. In this test file, the concurrent test forGetReadClient()(lines 132–157) now uses the simplified client methods without passing an error channel. Please verify that all callers (both in production and tests) have been updated consistently so that no stale “ech” parameters remain.apis/swagger/v1/vald/upsert.swagger.json (1)
17-19: Enhanced /upsert endpoint documentation
The updated summary now includes a detailed overview along with a status code table and troubleshooting guidance. This added structure greatly improves clarity regarding the Upsert RPC behavior. Please double-check that the markdown table (or equivalent text formatting) renders consistently in your Swagger UI.apis/swagger/v1/vald/update.swagger.json (2)
17-19: Expanded /update endpoint summary and description
The revised documentation for the/updateendpoint now provides a detailed explanation together with a structured status code table and troubleshooting advice. This change helps clarify possible error scenarios and corrective actions. Please ensure that the format (especially the table layout) integrates well with your API docs renderer.
50-52: Clear documentation for /update/multiple endpoint
Similar to the upsert changes, the multi-update endpoint now states its purpose clearly with notes on message size limitations and includes troubleshooting guides. The updated description enhances consistency across endpoints.internal/net/grpc/pool/pool.go (5)
17-20: Great documentation for the package overview.
These lines clearly state the lock-free approach and the additional features like DNS lookup and metrics collection. Looks good!
49-71: Interface expansion note.
The new methods (IsIPConn,Len,Size,String) add valuable insights into the connection pool’s state but potentially break backward compatibility for any existing code implementing this interface. Verify that no external consumers rely on the old interface definition, or provide default implementations if needed.
79-121: Repeated connection closure caution.
TheClosemethod attempts multiple calls topc.conn.Close()in a loop until the connection is fully shut down. While this is a robust approach, confirm that repeated invocations ofClose()on a gRPCClientConnobject won’t introduce unexpected behavior or race conditions across different runtime versions.
387-408: Clear single vs. multiple IP-based logic.
This method cleanly splits the connection logic into single-target and DNS-based flows. This separation improves readability. Ensure thatenableDNSLookupis defaulted or validated upstream so that logic remains consistent across different usage scenarios.
515-557: Backoff strategy confirmation.
Thedialmethod uses a backoff strategy whenp.bo != nil. Ensure the chosen backoff library and default parameters are appropriate for your environment—especially in production scenarios with frequent transient network failures.apis/swagger/v1/vald/insert.swagger.json (1)
50-51: Enhanced multi-insert summary.
The updated summary more clearly explains that multiple vectors can be inserted at once. Nicely done, and it aligns with the pattern used across other swagger definitions in the project.apis/swagger/v1/vald/search.swagger.json (7)
17-18: Comprehensive linear search documentation.
These lines effectively describe the functionality, status codes, and troubleshooting tips. Good addition for users needing immediate clarity.
50-51: Clarity on search by ID.
The summary highlights that the ID must be indexed beforehand. This is an essential detail; well done.
83-84: Multi-ID linear search doc block.
Including the “message size limitation” notice in the description is helpful for preventing unexpected overhead. No issues found.
116-117: Clear multi-vector workflow.
Line 116 clarifies multi-vector searching. The consistent structure with the other endpoints is appreciated.
149-150: High-level search explanation with status code references.
This block is well-structured, making it easier for end-users to see how to debug potential errors.
215-216: Multiple ID search consolidation.
The format, including the troubleshooting table, is consistent with the single-ID version. This uniformity is beneficial across the docs.
248-249: Parallel multi-search endpoints.
Mirrors the multi-linear approach. Everything appears coherent and matches the established pattern.apis/docs/v1/docs.md (1)
1940-1942: Upsert Service Overview Approval
The overview for the Upsert service is clear and effectively conveys that the service both updates existing vectors and inserts new ones if they do not already exist. No changes are necessary here.apis/swagger/v1/vald/filter.swagger.json (5)
49-49: Enhanced MultiInsertObject RPC DetailsThe revised summary for the
/insert/object/multipleendpoint now clearly explains the multi-insert operation and lists status codes in a well-organized table. This change significantly enhances the API documentation clarity.
81-81: Improved SearchObject RPC DescriptionThe updated summary for the
/search/objectendpoint provides more context and a clear status code table. The inclusion of detailed status information is beneficial for troubleshooting.
145-145: Concise UpdateObject RPC SummaryThe update for the
/update/objectendpoint now presents a complete and succinct description of the UpdateObject RPC with clearly tabulated status codes.
210-210: Thorough UpsertObject RPC SummaryThe revised summary for the
/upsert/objectendpoint now provides a clear overview with a structured table of status codes, improving the clarity of the API documentation.
242-243: Comprehensive MultiUpsertObject RPC DetailsThe summary and description for the
/upsert/object/multipleendpoint now outline the method’s functionality, including the message size limitation warning and a detailed status code table. The consistency with the other endpoints is commendable.apis/swagger/v1/vald/object.swagger.json (3)
17-18: Robust Exists RPC DocumentationThe updated summary and description for the
/exists/{id}endpoint provide a detailed overview of the Exists RPC, including troubleshooting steps and a clear status code table. This added detail will help users understand common failure modes and resolutions.
77-77: Informative Metadata RPC OverviewThe summary for
/object/meta/{id.id}now follows the new structured style by including an "Overview" and placeholders for the status codes and troubleshooting sections. It would be beneficial to update the TODO sections with concrete details soon.
106-107: Enhanced GetObject RPC DetailsThe updated summary and description for
/object/{id.id}now comprehensively detail the GetObject RPC. The detailed troubleshooting steps and the status code table make it much easier for developers to interpret responses.apis/swagger/v1/vald/remove.swagger.json (3)
17-18: Comprehensive Remove RPC SummaryThe revised summary and description for the
/removeendpoint now include an extensive status code table and troubleshooting section. This level of detail is very useful for understanding possible error scenarios.
50-52: Detailed MultiRemove RPC DescriptionThe new summary and description for the
/remove/multipleendpoint clearly articulate the operation, including a note on the gRPC message size limitation. The extended troubleshooting table is a strong addition for developers.
83-84: Thorough RemoveByTimestamp RPC OverviewThe updated summary for the
/remove/timestampendpoint now explains the operation clearly, including the use of multiple timestamps with an AND condition. The detailed description provides both operational context and troubleshooting advice, which will help users understand how to resolve issues.
There was a problem hiding this comment.
Actionable comments posted: 19
🔭 Outside diff range comments (2)
internal/net/grpc/option.go (1)
656-663:⚠️ Potential issueFunction renamed for terminology consistency
Renaming from
WithOldConnCloseDurationtoWithOldConnCloseDelayimproves terminology consistency across the codebase.This is a breaking change to a public API. Ensure all call sites are updated to use the new function name. Consider retaining the old function as deprecated for a transition period if there might be external consumers of this API.
+// WithOldConnCloseDuration is deprecated, use WithOldConnCloseDelay instead +func WithOldConnCloseDuration(dur string) Option { + return WithOldConnCloseDelay(dur) +}pkg/agent/core/ngt/service/ngt.go (1)
1842-1857: 🛠️ Refactor suggestionAdd a rollback or retry mechanism for partial file moves.
The move-and-switch logic can fail mid-operation, which could leave the index data in an inconsistent state. Consider implementing a fallback strategy or retry logic to ensure a graceful recovery if any
MoveDircall fails.
♻️ Duplicate comments (6)
dockers/dev/Dockerfile (1)
143-143: 🛠️ Refactor suggestionSecurity Best Practice: Avoid Using Root as Final User
The Dockerfile concludes by settingUSER root:root. In line with best practices and previous feedback, consider using a non-root user to enhance container security. For example:-USER root:root +USER appuser:appuserIf running as root is strictly necessary for your workflow, please document the rationale.
internal/net/grpc/metadata_test.go (1)
18-101:⚠️ Potential issueImplement test cases for
TestNewMetadatainstead of leaving them as TODOsThe newly added
TestNewMetadatafunction is well-structured but currently commented out with empty test cases. To properly test theNewMetadatafunction, please implement the concrete test cases that verify its behavior with empty maps, single key-value pairs, and multiple key-value pairs.This is a duplicate of a previous review comment. Please prioritize implementing these test cases to improve coverage for the
NewMetadatafunction as previously suggested.internal/file/file_test.go (1)
1523-1606:⚠️ Potential issueTest structure without implementation
A test function for the
AbsolutePathfunction has been added, but it contains no actual test cases - only commented-out TODO placeholders.While the test structure follows the standard pattern used throughout the codebase, without concrete test cases, there's no test coverage for the new
AbsolutePathfunction. Please implement actual test cases to validate various scenarios:{ name: "returns empty string when path is empty", args: args{ path: "", }, want: want{ want: "", }, checkFunc: defaultCheckFunc, }, { name: "returns absolute path unchanged", args: args{ path: "/absolute/path", }, want: want{ want: "/absolute/path", }, checkFunc: defaultCheckFunc, }, { name: "converts relative path to absolute path", args: args{ path: "relative/path", }, beforeFunc: func(t *testing.T, args args) { t.Helper() // Test needs special handling due to working directory dependency }, checkFunc: func(w want, got string) error { // Custom check that verifies got is absolute path ending with relative/path if !filepath.IsAbs(got) { return errors.New("path not absolute") } if !strings.HasSuffix(got, "relative/path") { return errors.Errorf("unexpected path: %s", got) } return nil }, }.gitfiles (1)
1966-1966:⚠️ Potential issueUpdate error handling in new Rust components.
The Rust components added here represent a significant enhancement to the codebase with the object handler, test client, and QBG algorithm implementation.
Per the retrieved learning from PR #2807, there's a critical pattern to follow: avoid using
unwrap()on Option types in Rust handlers. Based on previous reviews, there are instances likehostname.to_str().unwrap()in the object.rs file that need to be replaced with explicit None value handling by returning appropriate error statuses. This pattern should be applied across all the new Rust components.Also applies to: 1976-1976, 1986-1990
cmd/index/job/deletion/main_test.go (2)
68-68:⚠️ Potential issueMissing import for goleak
The code references
goleak.VerifyNone()but there's no import statement for the goleak package. When implementing the test, make sure to add:import ( "testing" "github.com/vdaas/vald/internal/test/goleak" )
80-80: 🛠️ Refactor suggestionDirect call to main() without mocking
Calling the actual
main()function in tests can have side effects like exiting the program. Consider using dependency injection or creating a testable version of main that accepts mocked dependencies.- main() + testableMain(mockDependencies...)
🧹 Nitpick comments (69)
dockers/index/job/creation/Dockerfile (1)
89-89: Redundant ENTRYPOINT Change Detected
The change on line 89 re-specifies the ENTRYPOINT using the identical command (["/usr/bin/index-creation"]). While this does not alter the image's behavior, please ensure that this duplicate redeclaration is intentional and not an artifact of automated code generation or refactoring.dockers/tools/benchmark/job/Dockerfile (1)
96-97: ENTRYPOINT Instruction ReviewThe
ENTRYPOINT ["/usr/bin/job"]instruction is now explicitly placed, and the change appears to be a cosmetic adjustment (likely a newline removal issue) that does not alter the container's runtime behavior. Please verify that any external configurations (e.g., Helm charts) or related integrations consistently reference this entrypoint.internal/iter/iter.go (2)
22-23: Avoid potential cyclical package import naming.Importing
"iter"within the same"package iter"can be confusing or may introduce cyclical import problems. Consider renaming one to avoid conflicts, such as using a distinct import alias or renaming the package to something else (e.g.,iterlib).
52-59: Consider returning a non-nil instance or an error rather than nil for invalid input.Currently,
NewCyclereturnsnilif the passedarrayisnilor empty. In Go, returning anilinterface for invalid input can lead to runtime panics if a caller attempts to call its methods. It is often more idiomatic to either return a zero-length iterator object (that safely no-ops) or return an error indicating invalid arguments.-func NewCycle[S ~[]E, E any](array S, num, offset uint64, mod func(uint64, E) E) Cycle[S, E] { - if array == nil { - return nil - } - size := uint64(len(array)) - if size == 0 { - return nil - } +func NewCycle[S ~[]E, E any](array S, num, offset uint64, mod func(uint64, E) E) (Cycle[S, E], error) { + if array == nil { + return nil, errors.New("array cannot be nil") + } + size := uint64(len(array)) + if size == 0 { + return nil, errors.New("array cannot be empty") + }apis/swagger/v1/vald/search.swagger.json (3)
50-51: Enhanced Documentation for/linearsearch/idEndpointThe revised summary and description now clearly explain the endpoint’s purpose and error handling, with additional emphasis (using
<br>) for clarity. Please double-check that these HTML tags render as intended in your final docs.
83-84: Enhanced Documentation for/linearsearch/id/multipleEndpointThe updated summary now details that this endpoint handles multiple IDs and includes a notice about gRPC message size limitations. Consider removing the inline comment
// ---if it is not intended for the end-user documentation.
182-183: Enhanced Documentation for/search/idEndpointThe updated summary now includes an HTML
<br>for a clearer layout and explains the pre-indexing requirement. Ensure that the usage of HTML tags (e.g.,<br>) properly renders in the final API docs.internal/config/benchmark_test.go (1)
16-16: Consider implementing these test casesThese tests are currently commented out with "NOT IMPLEMENTED BELOW". Since you're adding a new field to the structs, it might be a good time to implement these test cases to ensure proper functionality of the Bind methods, especially with the new Meta field.
Makefile.d/functions.mk (1)
144-144: Consider documenting the expected dataset formatThe E2E_DATASET_PATH is set to point to a specific dataset location. Consider adding a comment indicating the format expected for this dataset to help other developers properly configure their tests.
Makefile.d/minikube.mk (1)
25-35: Consider adding a smoke test for minikube setupSince the minikube setup is critical for the E2E testing environment, consider adding a simple validation step after startup to verify that minikube is properly configured with all required addons.
minikube start --driver=docker --force minikube addons enable volumesnapshots minikube addons enable csi-hostpath-driver minikube addons disable storage-provisioner minikube addons disable default-storageclass kubectl patch storageclass csi-hostpath-sc -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + @echo "Verifying minikube setup..." + @minikube status | grep -q "host: Running" || (echo "Error: Minikube is not running properly" && exit 1) + @kubectl get sc csi-hostpath-sc -o jsonpath='{.metadata.annotations.storageclass\.kubernetes\.io/is-default-class}' | grep -q "true" || (echo "Error: Default storage class not configured properly" && exit 1) + @echo "Minikube setup verified successfully"internal/net/grpc/status/status.go (1)
48-50: New utility function enhances error handlingThis function provides a convenient way to check if an error has a specific gRPC status code, making error handling more concise and readable. The implementation is simple and follows Go idioms (similar to
errors.Is).Consider adding a unit test for this function to ensure it correctly handles nil errors and various status code scenarios.
apis/swagger/v1/mirror/mirror.swagger.json (1)
17-17: Documentation improvement with status codesThe enhanced API documentation now provides a clear overview of the endpoint's purpose and includes a structured status code table, making it more developer-friendly.
For consistency, consider extending this documentation pattern to other endpoints in the API. Also, you might want to include example requests/responses to further enhance usability.
internal/net/net.go (1)
199-207: Enhanced host resolution with fallback mechanismThe address resolution logic has been improved by adding a fallback mechanism using
DefaultResolver.LookupIPAddrwhen the initial parsing fails. This change makes the hostname resolution more robust and provides more detailed error information.Consider moving the DNS resolution logic to a separate helper function to improve readability and maintainability. This would make the
Parsefunction cleaner and more focused on its primary responsibility.ip, nerr := netip.ParseAddr(host) if nerr != nil { - ips, err := DefaultResolver.LookupIPAddr(context.Background(), host) - if err != nil || ips == nil || len(ips) == 0 { - log.Debugf("host: %s,\tport: %d,\tip: %#v,\tParseAddr error: %v, LookupIPAddr error:", host, port, ip, nerr, err) - } else { - ip, nerr = netip.ParseAddr(ips[0].String()) - if nerr != nil { - log.Debugf("host: %s,\tport: %d,\tip: %#v,\tParseAddr error: %v", host, port, ip, nerr) - } - } + ip, nerr = tryDNSResolution(host, port, ip, nerr) } // Add a helper function elsewhere in the file: // func tryDNSResolution(host string, port uint16, ip netip.Addr, originalErr error) (netip.Addr, error) { // ips, err := DefaultResolver.LookupIPAddr(context.Background(), host) // if err != nil || ips == nil || len(ips) == 0 { // log.Debugf("host: %s,\tport: %d,\tip: %#v,\tParseAddr error: %v, LookupIPAddr error: %v", host, port, ip, originalErr, err) // return ip, originalErr // } // // resolvedIP, resolveErr := netip.ParseAddr(ips[0].String()) // if resolveErr != nil { // log.Debugf("host: %s,\tport: %d,\tip: %#v,\tParseAddr error: %v", host, port, ip, resolveErr) // return ip, originalErr // } // // return resolvedIP, resolveErr // }internal/net/net_test.go (1)
1199-1369: Consider implementing the outlined test functions or removing the commented code.There are two test function skeletons (TestIsUDP and TestIsTCP) that are commented out. Either implement these tests or remove the commented code to maintain a cleaner codebase. If they represent pending work, consider adding a TODO comment instead.
-// -// func TestIsUDP(t *testing.T) { -// type args struct { ... -// } -// } +// TODO: Implement TestIsUDP and TestIsTCP to verify network type detectioninternal/net/grpc/status/status_test.go (1)
245-331: The new test template follows consistent code structure.The added
TestIstest function template follows the established pattern in this file, with appropriate structure for test cases, default check function, and parallel execution. This will be useful when implementing test cases for theIsfunction which likely verifies if an error corresponds to a specific gRPC status code.Consider implementing actual test cases for the
Isfunction along with this template, especially as part of the improved error handling mentioned in the PR objectives. This would increase test coverage immediately rather than leaving it for future implementation.internal/errors/errors_test.go (1)
1737-1826: Implement theTest_isunit testsThis commented-out test function is for the internal
isfunction that's a critical part of error comparison logic. Since other functions likeIs,IsAny, andIsNotdepend on this implementation, it's essential to have thorough test coverage for it.I can help implement test cases for this function if needed. Consider these test scenarios:
- Both
errandtargetare nil- Only
erris nil- Only
targetis nil- Both are the same error (direct comparison)
- Wrapped errors with
Ismethod implementation- Errors with different messages
- Different error types implementing the
Unwrap() errormethod- Different error types implementing the
Unwrap() []errormethodinternal/errors/errors.go (1)
86-88: Add documentation comment toErrUnimplementedThis is a new error generator function, but unlike other error generators in this file, it doesn't have a descriptive comment explaining its purpose and usage.
Add a descriptive comment similar to other error generators:
+// ErrUnimplemented represents a function to generate an error that a feature is unimplemented. ErrUnimplemented = func(name string) error { return Errorf("%s is unimplemented", name) }internal/net/grpc/errdetails/errdetails.go (1)
93-94: Improved MarshalJSON error handling with better type mapping.The changes to the
MarshalJSONmethod include:
- Better type URL handling with prefix trimming
- Addition of a default case using
protojson.Marshalfor unknown types- Enhanced error handling with logging
These improvements make the error details serialization more robust and informative.
Consider optimizing the double prefix trimming.
While the current implementation works correctly, consider combining the two
strings.TrimPrefixcalls into a single operation for better performance.-typeName := strings.TrimPrefix(strings.TrimPrefix(d.TypeURL, typePrefix), typePrefixV1) +typeName := strings.TrimPrefix(d.TypeURL, typePrefix) +if strings.HasPrefix(typeName, typePrefixV1[len(typePrefix):]) { + typeName = strings.TrimPrefix(typeName, typePrefixV1[len(typePrefix):]) +}Or alternatively, use a regex-based approach if this pattern occurs frequently.
Also applies to: 165-173
internal/net/http/client/client_test.go (1)
195-285: Consider implementingTestNewWithTransportto improve test coverageThe commented-out
TestNewWithTransportfunction would provide valuable test coverage for client creation with custom transports. Consider implementing it to ensure this functionality works as expected.-// NOT IMPLEMENTED BELOW -// -// func TestNewWithTransport(t *testing.T) { +func TestNewWithTransport(t *testing.T) {And complete the test cases implementation to test the
NewWithTransportfunction with various scenarios (default transport, custom transport, handling of option errors, etc.).internal/sync/errgroup/group_test.go (1)
1172-1289: Commented out old test functionThe
Test_group_TryGofunction has been fully commented out but preserved in the file. This is good for reference while transitioning to the new function name and signature, but should be removed when no longer needed.Consider removing this commented-out test function once the migration to
Test_group_execis complete and all functionality has been properly tested. This would improve code maintainability by removing unused code.internal/net/quic/listener_test.go (2)
18-111: Well-structured test skeleton for Listen functionThe test skeleton follows a good table-driven testing pattern with appropriate types for arguments, expected results, and checking functions. It also includes parallel test execution setup.
When implementing the actual test cases, consider adding tests for error conditions like invalid addresses, nil TLS configs, and contexts that are already canceled.
113-207: Well-structured test skeleton for Accept methodThe test skeleton for the
Listener_Acceptmethod follows the same organized pattern as the other test function, making the code consistent and maintainable.When implementing the actual test cases, consider adding tests for connection timeouts, closed listeners, and context cancellations during accept operations.
internal/test/data/vector/noise/option.go (1)
37-56: Well-documented option functionsEach option function is clearly documented explaining its purpose. The functions follow a consistent pattern and naming convention.
Consider adding parameter validation for these option functions, such as checking for negative values or unreasonably large numbers that might cause issues. For example:
func WithLevelFactor(f float32) Option { return func(ng *noiseGenerator) { // Ensure noise level factor is positive if f < 0 { f = 0 } ng.noiseLevelFactor = f } }internal/client/v1/client/discoverer/discover_test.go (2)
32-130: Review of Test_client_GetReadClientThe test sets up multiple scenarios to differentiate between returning the primary client versus the read client based on the atomic counter value. The logic appears sound:
- When no read replica exists, the primary client is returned.
- In cases where a read replica is configured, the test correctly distinguishes between a “counter at zero” (returning the primary client) and nonzero values (returning the read client).
Additionally, note that the removal of the formerly unused
echparameter (as explained in the PR summary) now means that all invocations are simplified. Please ensure that all upstream test calls or any helper functions expecting the old signature have been updated accordingly.
159-249: Commented Test Stubs and Legacy CodeA large block of commented-out test functions (e.g.,
TestNew,Test_client_Start, etc.) remains in the file. These appear to be placeholders or legacy code that have been disabled.
- Consider either updating, re-enabling, or removing these sections to minimize clutter and avoid confusion in future maintenance.
apis/swagger/v1/vald/index.swagger.json (5)
15-17: Swagger Update for /index/detailThe
summaryfield now includes a new prefix ("Overview\n") followed by the previous description. This update improves consistency by drawing attention to the overview aspect of the RPC.
- Make sure that the newline character (
\n) is rendered correctly in all Swagger documentation viewers.
36-38: Swagger Update for /index/infoThe summary now begins with "Overview" followed by a newline and the original description. This enhancement maintains uniformity with other endpoints.
- Ensure that formatting is preserved in generated client documentation.
57-59: Swagger Update for /index/propertyThe updated summary now starts with "Overview\n". This standardization is in line with other changes—confirm that display tools (such as Swagger UI) properly interpret the newline.
78-80: Swagger Update for /index/statisticsThe change prepends "Overview" (with a newline) to the original summary. It is consistent with the other endpoints.
99-102: Swagger Update for /index/statistics/detailAgain, the summary now includes the prefix "Overview" with a newline. This update should contribute to a more standardized API documentation style.
- Verify that the updated description is clear to API consumers.
internal/config/config.go (1)
120-125: Clarify in-place modification of the slice.
GetActualValuesmodifies the input slice in place by callingGetActualValueon each element. This behavior can be surprising or undesirable if callers expect an immutable operation. Consider documenting or returning a new slice for clarity.internal/params/params.go (6)
23-23: Confirm Go version support for 'slices' package.
sliceswas introduced in Go 1.21 (stable). Ensure the minimum Go version for your project is set accordingly in your build configuration or documentation.
54-58: Consider doc comments for clarity.
These new struct fields (overrideDefault,name,filters,f,defaults) affect parsing logic. Adding comments to clarify their usage might aid future maintainers.
78-79: Initialize flag sets thoughtfully.
Assigningp.defaultstoflag.CommandLineand creating a new FlagSet forp.fis fine. Just be aware of potential concurrency issues ifflag.CommandLineis also used elsewhere.
81-81: Watch for side effects inp.Override().
Overridingflag.CommandLineglobally can affect other packages that rely on default flags. Minimizing global state modifications can help avoid unexpected behaviors.
139-143:Restore()reverts global flags.
Resetting to the originalflag.CommandLineis a valid approach but be mindful of concurrency or external usage of the global flags.
145-149: Overriding global flags withOverride().
This technique can be powerful but might create conflicts if multiple parsers override global flags. Proceed carefully.pkg/index/job/deletion/service/deleter_test.go (5)
18-105:TestNewis unimplemented.
This test function is only scaffolding. Consider adding real test cases or removing unused stubs to maintain a clean codebase.Would you like help drafting sample assertions?
107-190:Test_delDuplicateAddrsplaceholder.
No actual test scenarios are provided. Implement test logic to ensure address deduplication is validated, or remove if unneeded.
192-304:Test_index_StartClientplaceholder.
Currently, it lacks concrete input-output checks. Include test cases that simulate real discoverer client usage or remove if not needed.
306-414:Test_index_Startplaceholder.
No coverage of concurrency or error-handling. Add relevant test logic to validate index startup or remove the empty function block.
416-527:Test_index_doDeleteIndexplaceholder.
No test logic is implemented. Introduce real scenarios to confirm index deletion error handling or remove the stub test.internal/errors/k8s.go (1)
20-46: Consider standardizing the capitalization within error messages.All newly introduced Kubernetes-related error variables are well-defined and helpful. However, notice that some messages begin with lowercase (e.g.,
"invalid reconciler config") while others use uppercase (e.g.,"Undefined namespace"). For consistency, consider adopting a single style across all error messages.apis/swagger/v1/vald/insert.swagger.json (1)
17-18: Fix the minor spelling in the summary.
The summary has "Inset RPC" instead of "Insert RPC," which could confuse readers. Please correct the spelling to align with the endpoint’s functionality.- "summary": "Overview\nInset RPC is the method to add a new single vector.\n---\nStatus Code...", + "summary": "Overview\nInsert RPC is the method to add a new single vector.\n---\nStatus Code...",internal/net/grpc/pool/option.go (1)
41-54: Consider logging fallback to host-only address.
Splitting the host and port withnet.SplitHostPortis helpful. On error, the code silently falls back to settingp.host = addr. For easier debugging, consider logging the fallback scenario.if p.host, p.port, err = net.SplitHostPort(addr); err != nil { + // Log or trace the split failure if desired p.host = addr }internal/sync/errgroup/group.go (1)
204-215: Centralized error recording.
Storing errors by message string prevents duplicates. This helps debug concurrency issues, though consider a more robust key if collisions occur.apis/docs/v1/docs.md (6)
1372-1373: Mirror Service Overview Addition
The new "Overview" section for the Mirror service clearly states its primary responsibility—providing theRegisterinterface for the Vald Mirror Gateway. Please double-check that the terminology (e.g. “Register interface”) is consistent with other service descriptions across the documentation.
1636-1638: Filter Service Overview Enhancement
The added "Overview" for the Filter service enhances clarity by summarizing its role in providing insert, update, upsert, and search interfaces through the Vald Filter Gateway. Consider revising the sentence "Vald Filter Gateway forward user request to user-defined ingress/egress filter components allowing user to run custom logic" to "Vald Filter Gateway forwards user requests to user-defined ingress/egress filter components, allowing users to run custom logic" for grammatical accuracy and consistency.
1691-1691: Index Service Overview Addition
The inclusion of an "Overview" header in the Index service section is a welcome improvement that immediately informs the reader of its role ("Represent the index manager service."). In future updates, you might consider expanding this description slightly to offer more context.
1714-1715: Insert Service Overview Clarification
The inserted "Overview" for the Insert service now clearly states its role in inserting new vectors into thevald-agent. Please verify that the terminology in the subsequent table is consistent; for instance, the table mentions "Inset RPC" which appears to be a typographical error and should likely read "Insert RPC."
1822-1823: Search Service Overview Introduction
The added overview for the Search service explains its function of finding vectors similar to the user request vector. For improved clarity, consider rephrasing "fromvald-agent" to "in thevald-agent" to accurately reflect the context in which the search is performed.
1906-1907: Update Service Overview Improvement
The new "Overview" for the Update service describes its purpose; however, the phrase "updates to new vector from inserted vector" might be unclear. A suggested revision could be: "Update Service is responsible for updating existing vectors in thevald-agent." This change would enhance clarity and align with the style of the other service overviews.example/client/go.mod (1)
28-28: Dependency version consistency.
google.golang.org/grpcis required here at v1.71.0, while replaced in line 17 at v1.71.1. Consider aligning these versions if possible, to avoid confusion or potential conflicts.internal/net/grpc/pool/pool.go (3)
79-121: Validate the repeated close logic.While the delayed closure loop (lines 81-121) helps ensure a graceful shutdown, calling
pc.conn.Close()repeatedly in a loop could be fragile. If closure errors persist for reasons other than cancellation, you might be stuck in a re-close loop. Consider introducing a limit or a simpler condition check to prevent potential infinite attempts.
607-633: Check 'IsHealthy' logic for IP-based pools.When
p.isIPAddris true, all slots must be healthy. This is strict but could be beneficial for pure IP-based connections. Confirm if certain partial failures (e.g., ephemeral connectivity issues) might cause unnecessary reconnections or downtime. If partial connectivity is acceptable, you may want to handle it more gracefully.Would you like a follow-up snippet to handle partial IP-based connectivity scenarios?
740-770: Potential idle connection pitfall in isHealthy.Lines 753-762 attempt to reconnect idle connections asynchronously. If the reconnection doesn’t succeed within the
WaitForStateChangeinterval, the function permanently marks the connection unhealthy. This can potentially degrade availability if the dial or ephemeral network fluctuations take slightly longer. Consider a fallback or a longer wait interval for slow networks.apis/swagger/v1/vald/remove.swagger.json (3)
17-19: Enhanced/removeEndpoint Documentation
The updated summary and description now provide a comprehensive overview including status codes and troubleshooting steps. This additional detail greatly improves the clarity for API consumers. Please verify that the multi-line markdown formatting (e.g., tables and line breaks) renders as expected in your API documentation tools.
50-53: Expanded/remove/multipleEndpoint Details
The richer summary and description now include an important warning regarding gRPC message size limitations. This added context is very useful for developers to avoid potential pitfalls during bulk remove operations. Double-check that table formatting (with bold markers) is consistently rendered across similar endpoints.
83-85: Improved/remove/timestampEndpoint Clarity
The extended summary and description for the timestamp-based removal endpoint now clearly document the behavior when using multiple timestamps (resulting in an AND condition) and offer detailed troubleshooting guidance. Ensure that the markdown-style formatting (especially for the table of common reasons and resolutions) remains uniform with the other endpoints..github/workflows/e2e.yaml (1)
45-47: Added container registry authentication for all E2E test jobs.Security enhancement that adds authentication credentials to all container configurations in the E2E workflow. This ensures containers can access potentially private container images during CI/CD pipeline execution.
Consider adding a comment at the top of the file explaining the necessity of these credentials for container registry access, to help future contributors understand their purpose.
Also applies to: 89-91, 156-158, 204-206, 248-250, 288-290, 325-327, 379-381
internal/test/data/vector/noise/option_test.go (1)
83-83: Ensure goleak import is added when implementing testsAll three test functions use
goleak.VerifyNone()but will need the import when uncommented:import ( "reflect" "testing" "github.com/vdaas/vald/internal/errors" "github.com/vdaas/vald/internal/test/goleak" )Also applies to: 168-168, 253-253
pkg/agent/core/ngt/service/ngt_test.go (2)
11318-11318: Updated function call with context.The loadStatistics function call has been properly updated to pass the context from test arguments.
Consider adding test cases that validate the context-awareness of loadStatistics, such as testing with cancellation or timeouts, to ensure proper context handling.
11120-11122:❓ Verification inconclusive
Consider using context.Background() instead of nil.
Using
nilfor context might lead to nil pointer dereferences if the function being tested attempts to call methods on the context. It's safer to usecontext.Background()orcontext.TODO()as the default value.// args: args { - ctx:nil, + ctx:context.Background(), // },Also applies to: 11188-11190
🏁 Script executed:
#!/bin/bash # Check if loadStatistics() uses ctx methods that would fail with nil rg -A 3 "loadStatistics.*ctx\." pkg/agent/core/ngt/service/Length of output: 61
Action Required: Replace nil with context.Background() in test initialization
The test file pkg/agent/core/ngt/service/ngt_test.go uses
nilas the context in two places (lines 11120–11122 and 11188–11190). Since passing a nil context can lead to runtime nil pointer dereferences when methods on the context are invoked, it’s recommended to switch to a safe default likecontext.Background().// args: args { - ctx: nil, + ctx: context.Background(), // },Please verify that none of the functions under test (e.g., any usage within loadStatistics) rely on a nil check or have special handling for a nil context. Manual confirmation is advised to ensure that this update is safe in all test scenarios.
internal/test/data/vector/noise/noise_test.go (2)
16-107: Implement or remove the placeholder test cases forTestNew.You have a skeleton test structure here with many commented-out sections, but no real execution or assertions. Please add real test cases or remove these placeholders to maintain clarity and ensure comprehensive test coverage.
109-207: Add test cases forTest_noiseGenerator_Mod.Similarly, the entire body for testing
Mod()is commented out. Consider providing actual test cases to confirm that the noise generator works as intended. This will help validate your noise table usage and ensure correct behavior.pkg/agent/core/ngt/service/ngt.go (3)
887-955: Consider refactoring theStartmethod for improved maintainability.The
Startmethod contains multiple looping mechanisms, tickers, and condition checks. Its length and complexity make it harder to follow and maintain. Consider extracting smaller functions or a state machine approach to improve readability and reduce complexity.
1475-1478: Handle the nilstatsscenario more explicitly.When
stats == nil, you only log a warning and continue. Consider returning an error or handling it explicitly if the usage of these statistics is essential. Relying solely on logs may lead to missed issues downstream.
1973-1980: Consider explicitly logging when context errors are skipped.When the context is canceled or expires, the code merges those errors into existing ones only if they don't match the excluded list. Clarifying the skip condition via logs can aid debugging and avoid confusion.
internal/test/data/vector/noise/noise.go (1)
74-76: Consider reducing log verbosity during noise table precomputation.Using
log.Infoffor every noise table construction can clutter logs in large-scale scenarios. Either raise the logging threshold (e.g.,Debugf) or provide a toggle to silence logs for production environments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (31)
apis/grpc/v1/agent/core/agent.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/agent/sidecar/sidecar.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/discoverer/discoverer.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/egress/egress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/filter/ingress/ingress_filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/meta/meta.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/mirror/mirror_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/payload/payload.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/rpc/errdetails/error_details.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/filter_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/flush_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/index_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/insert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/object_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/remove_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/search_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/update_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert.pb.gois excluded by!**/*.pb.go,!**/*.pb.goapis/grpc/v1/vald/upsert_vtproto.pb.gois excluded by!**/*.pb.go,!**/*.pb.goexample/client/go.sumis excluded by!**/*.sumgo.sumis excluded by!**/*.sumrust/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (153)
.gitfiles(15 hunks).github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/security_issue_report.md(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks).github/workflows/_docker-image.yaml(1 hunks).github/workflows/_release-pr.yaml(1 hunks).github/workflows/build-binaries.yaml(1 hunks).github/workflows/build-protobuf.yaml(1 hunks).github/workflows/chatops.yaml(5 hunks).github/workflows/codeql-analysis.yml(2 hunks).github/workflows/coverage.yaml(1 hunks).github/workflows/e2e-chaos.yaml(4 hunks).github/workflows/e2e-code-bench-agent.yaml(2 hunks).github/workflows/e2e-max-dim.yaml(1 hunks).github/workflows/e2e-profiling.yaml(1 hunks).github/workflows/e2e.yaml(8 hunks).github/workflows/format.yaml(3 hunks).github/workflows/fossa.yaml(1 hunks).github/workflows/helm-lint.yaml(3 hunks).github/workflows/helm.yaml(2 hunks).github/workflows/reviewdog-k8s.yaml(3 hunks).github/workflows/reviewdog.yaml(2 hunks).github/workflows/test-hack.yaml(1 hunks).github/workflows/unit-test-rust.yaml(1 hunks).github/workflows/unit-test.yaml(3 hunks).github/workflows/update-deps.yaml(1 hunks)Makefile(8 hunks)Makefile.d/e2e.mk(1 hunks)Makefile.d/functions.mk(1 hunks)Makefile.d/minikube.mk(1 hunks)Makefile.d/tools.mk(2 hunks)apis/docs/v1/docs.md(10 hunks)apis/swagger/v1/mirror/mirror.swagger.json(1 hunks)apis/swagger/v1/vald/filter.swagger.json(8 hunks)apis/swagger/v1/vald/flush.swagger.json(1 hunks)apis/swagger/v1/vald/index.swagger.json(5 hunks)apis/swagger/v1/vald/insert.swagger.json(2 hunks)apis/swagger/v1/vald/object.swagger.json(4 hunks)apis/swagger/v1/vald/remove.swagger.json(3 hunks)apis/swagger/v1/vald/search.swagger.json(8 hunks)apis/swagger/v1/vald/update.swagger.json(3 hunks)apis/swagger/v1/vald/upsert.swagger.json(2 hunks)charts/vald/values/dev.yaml(1 hunks)cmd/index/job/deletion/main_test.go(1 hunks)dockers/agent/core/agent/Dockerfile(1 hunks)dockers/agent/core/faiss/Dockerfile(1 hunks)dockers/agent/core/ngt/Dockerfile(1 hunks)dockers/agent/sidecar/Dockerfile(1 hunks)dockers/binfmt/Dockerfile(1 hunks)dockers/buildbase/Dockerfile(1 hunks)dockers/buildkit/Dockerfile(1 hunks)dockers/buildkit/syft/scanner/Dockerfile(1 hunks)dockers/ci/base/Dockerfile(1 hunks)dockers/dev/Dockerfile(1 hunks)dockers/discoverer/k8s/Dockerfile(1 hunks)dockers/example/client/Dockerfile(1 hunks)dockers/gateway/filter/Dockerfile(1 hunks)dockers/gateway/lb/Dockerfile(1 hunks)dockers/gateway/mirror/Dockerfile(1 hunks)dockers/index/job/correction/Dockerfile(1 hunks)dockers/index/job/creation/Dockerfile(1 hunks)dockers/index/job/deletion/Dockerfile(1 hunks)dockers/index/job/readreplica/rotate/Dockerfile(1 hunks)dockers/index/job/save/Dockerfile(1 hunks)dockers/index/operator/Dockerfile(1 hunks)dockers/manager/index/Dockerfile(1 hunks)dockers/operator/helm/Dockerfile(1 hunks)dockers/tools/benchmark/job/Dockerfile(1 hunks)dockers/tools/benchmark/operator/Dockerfile(1 hunks)dockers/tools/cli/loadtest/Dockerfile(1 hunks)example/client/go.mod(2 hunks)example/client/go.mod.default(1 hunks)go.mod(14 hunks)hack/go.mod.default(4 hunks)internal/backoff/backoff.go(2 hunks)internal/backoff/backoff_test.go(1 hunks)internal/backoff/option.go(0 hunks)internal/backoff/option_test.go(0 hunks)internal/client/v1/client/discoverer/discover.go(1 hunks)internal/client/v1/client/discoverer/discover_test.go(5 hunks)internal/config/benchmark_test.go(4 hunks)internal/config/config.go(2 hunks)internal/config/config_test.go(1 hunks)internal/config/grpc.go(1 hunks)internal/config/index_deleter_test.go(1 hunks)internal/core/algorithm/usearch/usearch_test.go(16 hunks)internal/db/nosql/cassandra/option_test.go(8 hunks)internal/errors/errors.go(2 hunks)internal/errors/errors_test.go(1 hunks)internal/errors/k8s.go(1 hunks)internal/errors/params.go(1 hunks)internal/file/file.go(3 hunks)internal/file/file_test.go(1 hunks)internal/info/info_test.go(17 hunks)internal/iter/iter.go(1 hunks)internal/net/dialer_test.go(1 hunks)internal/net/grpc/client.go(13 hunks)internal/net/grpc/errdetails/errdetails.go(6 hunks)internal/net/grpc/metadata_test.go(1 hunks)internal/net/grpc/option.go(1 hunks)internal/net/grpc/option_test.go(46 hunks)internal/net/grpc/pool/option.go(1 hunks)internal/net/grpc/pool/option_test.go(6 hunks)internal/net/grpc/pool/pool.go(6 hunks)internal/net/grpc/pool/pool_bench_test.go(2 hunks)internal/net/grpc/server_test.go(2 hunks)internal/net/grpc/status/status.go(1 hunks)internal/net/grpc/status/status_test.go(1 hunks)internal/net/grpc/stream.go(4 hunks)internal/net/grpc/stream_test.go(4 hunks)internal/net/http/client/client.go(2 hunks)internal/net/http/client/client_test.go(3 hunks)internal/net/http/client/option_test.go(4 hunks)internal/net/net.go(1 hunks)internal/net/net_test.go(3 hunks)internal/net/quic/conn_test.go(1 hunks)internal/net/quic/listener_test.go(1 hunks)internal/params/option.go(2 hunks)internal/params/option_test.go(1 hunks)internal/params/params.go(4 hunks)internal/params/params_test.go(12 hunks)internal/rand/rand.go(1 hunks)internal/runner/runner.go(4 hunks)internal/servers/server/option_test.go(1 hunks)internal/servers/server/server.go(1 hunks)internal/servers/servers.go(3 hunks)internal/sync/errgroup/group.go(7 hunks)internal/sync/errgroup/group_test.go(16 hunks)internal/test/data/vector/gen.go(0 hunks)internal/test/data/vector/noise/noise.go(1 hunks)internal/test/data/vector/noise/noise_test.go(1 hunks)internal/test/data/vector/noise/option.go(1 hunks)internal/test/data/vector/noise/option_test.go(1 hunks)internal/test/mock/server_stream.go(1 hunks)internal/timeutil/time.go(3 hunks)internal/timeutil/time_test.go(1 hunks)k8s/agent/ngt/configmap.yaml(1 hunks)k8s/discoverer/deployment.yaml(1 hunks)k8s/gateway/gateway/lb/deployment.yaml(1 hunks)k8s/gateway/gateway/mirror/deployment.yaml(1 hunks)k8s/index/operator/deployment.yaml(1 hunks)k8s/manager/index/deployment.yaml(1 hunks)pkg/agent/core/faiss/service/faiss.go(3 hunks)pkg/agent/core/ngt/service/ngt.go(5 hunks)pkg/agent/core/ngt/service/ngt_test.go(8 hunks)pkg/agent/core/ngt/service/option_test.go(8 hunks)pkg/discoverer/k8s/service/discover_test.go(4 hunks)pkg/gateway/lb/handler/grpc/aggregation_test.go(2 hunks)pkg/gateway/lb/handler/grpc/handler_test.go(2 hunks)pkg/gateway/mirror/service/mirror.go(2 hunks)pkg/index/job/deletion/config/config_test.go(1 hunks)pkg/index/job/deletion/service/deleter_test.go(1 hunks)pkg/index/job/deletion/service/options_test.go(1 hunks)
💤 Files with no reviewable changes (3)
- internal/backoff/option.go
- internal/backoff/option_test.go
- internal/test/data/vector/gen.go
🧰 Additional context used
🧠 Learnings (1)
.gitfiles (1)
Learnt from: datelier
PR: vdaas/vald#2807
File: rust/bin/agent/src/handler/object.rs:36-38
Timestamp: 2025-04-01T12:29:37.305Z
Learning: In Rust code for Vald handlers, avoid using unwrap() on Option types. Instead, handle None values explicitly by returning appropriate error statuses to maintain robustness.
🧬 Code Definitions (7)
internal/net/grpc/client.go (3)
internal/errors/errors.go (3)
IsNot(182-192)IsAny(170-180)Is(163-168)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/net/grpc/status/status.go (3)
Error(125-127)FromError(185-257)Is(48-50)
pkg/agent/core/ngt/service/option_test.go (4)
pkg/agent/core/ngt/service/ngt.go (1)
New(194-199)pkg/agent/core/ngt/usecase/agentd.go (1)
New(55-162)internal/net/grpc/client.go (1)
New(129-154)internal/net/grpc/pool/pool.go (1)
New(168-254)
internal/servers/server/server.go (2)
internal/net/grpc/server.go (1)
ErrServerStopped(44-44)internal/file/file.go (1)
Join(555-565)
internal/net/grpc/errdetails/errdetails.go (2)
internal/info/info.go (1)
Detail(51-68)internal/net/grpc/proto/proto.go (2)
Message(29-29)Marshal(39-41)
internal/config/grpc.go (1)
internal/net/grpc/option.go (1)
WithOldConnCloseDelay(656-663)
internal/net/grpc/stream.go (1)
internal/net/grpc/status/status.go (5)
Is(48-50)Errorf(129-131)ParseError(133-183)Code(41-41)Error(125-127)
internal/net/grpc/pool/pool.go (4)
internal/errors/errors.go (3)
Is(163-168)IsNot(182-192)New(92-97)internal/net/grpc/status/status.go (2)
Is(48-50)New(44-46)internal/net/grpc/codes/codes.go (2)
Canceled(26-26)DeadlineExceeded(29-29)internal/net/grpc/option.go (1)
Option(41-41)
🪛 GitHub Actions: Run unit tests
Makefile
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
- GitHub Check: build / build
🔇 Additional comments (332)
dockers/discoverer/k8s/Dockerfile (1)
89-90: Formatting Adjustment: Newline Addition.This change ensures that the
ENTRYPOINT ["/usr/bin/discoverer"]directive ends with a newline. It aligns with similar formatting updates across the repository's Dockerfiles and does not affect the functionality of the container.dockers/operator/helm/Dockerfile (1)
110-110: Formatting Consistency: Removal of Trailing Newline in ENTRYPOINTThe change in the
ENTRYPOINTinstruction removes a trailing newline, which aligns the Dockerfile's formatting with the project’s standard conventions without affecting functionality.dockers/index/job/correction/Dockerfile (1)
89-90: Entry point formatting is consistent.
TheENTRYPOINTinstruction remains functionally identical to before. The inclusion of the newline (and the explicit marking with~on line 89) improves formatting consistency across the Dockerfiles without altering container behavior.dockers/buildkit/syft/scanner/Dockerfile (1)
20-21: Minor Formatting Improvement: Newline AddedThe diff only adds a newline at the end of the file, which is a standard practice to ensure proper file termination. No functional changes have been introduced.
dockers/binfmt/Dockerfile (1)
20-21: Minor Formatting Update: Newline at End of File
The only change in this Dockerfile is the inclusion of a newline character at the end, which aligns with best practices for file formatting and ensures compatibility with various tools and diff utilities.dockers/tools/cli/loadtest/Dockerfile (1)
96-97: Consistent Formatting for ENTRYPOINT InstructionThe change updates the ENTRYPOINT line to conform to our standard Dockerfile formatting. It removes an unnecessary newline and aligns the instruction with similar Dockerfiles in the repository, enhancing consistency and maintainability.
pkg/discoverer/k8s/service/discover_test.go (4)
125-129: Improved type safety with atomic.Pointer usageThe change from
atomic.Valueto strongly-typedatomic.Pointerwith specific generic type parameters is a good improvement. This provides better type safety, prevents potential runtime type assertions, and makes the code more self-documenting by clearly expressing the expected data structure.
291-295: Consistent type safety improvementsThis change follows the same pattern as the previous segment, maintaining consistency throughout the test code. The use of generics with
atomic.Pointerclearly defines the complex nested map structures, which improves code readability and prevents type-related errors.
457-461: Consistent atomic.Pointer implementationThe change aligns with the pattern established in the previous test functions, demonstrating a systematic approach to refactoring. This consistency is valuable for maintaining the codebase and understanding the data structures used across different components.
623-627: Completed type safety improvementsThis final set of changes completes the consistent application of the
atomic.Pointerpattern throughout the test file. The systematic replacement ofatomic.Valuewith typed pointers enhances the code's self-documentation and aligns with modern Go practices, particularly the effective use of generics.pkg/gateway/lb/handler/grpc/aggregation_test.go (5)
37-39: Update to the want struct to accommodate new return valueThe
wantstruct has been expanded to include a new fieldwantAttrsof type[]attribute.KeyValue. This change is necessary to support verification of the new attributes being returned by theaggregationSearchmethod.
46-46: Updated signature to match implementation changeThe
checkFuncsignature has been properly updated to accept the new[]attribute.KeyValueparameter, which aligns with the changes to theaggregationSearchmethod and thewantstruct.
50-50: Consistent update to defaultCheckFunc parametersThe
defaultCheckFuncdefinition has been updated to accept the additionalgotAttrsparameter, maintaining consistency with the updated function signature.
57-59: Added validation for new return valueAdded appropriate validation for the newly returned attributes using
reflect.DeepEqual, consistent with the existing verification pattern for the other return values.
157-158: Updated method call to handle new return valueThe call to
s.aggregationSearchand subsequent error check have been modified to accommodate the newgotAttrsreturn value. The change maintains consistency with the updated function signature.apis/swagger/v1/vald/object.swagger.json (4)
17-18: Comprehensive Summary and Description for/exists/{id}EndpointThe updated summary and description now provide a structured and detailed overview (including a status code table and troubleshooting guidance) that will be very helpful for API consumers. Please ensure that this format remains consistent across all endpoints.
47-47: TODO Placeholders in/object/listEndpoint SummaryThe summary still contains 'TODO' placeholders for the status code details and troubleshooting information. These placeholders should be replaced with the final content to complete the documentation.
77-77: TODO Placeholders in/object/meta/{id.id}Endpoint SummaryThere are still 'TODO' placeholders in the summary for this endpoint. It is important to update these fields with the intended status code details and troubleshooting steps or remove them if not required.
106-107: Consistent and Detailed Documentation for/object/{id.id}EndpointThe summary and description for this endpoint are comprehensive and maintain a consistent format with an explicit status code table and troubleshooting section. Consider a final pass to verify that the language and structure align perfectly with other endpoints.
internal/iter/iter.go (2)
80-94: Context cancellation is handled properly.The implementation correctly checks for
ctx.Done()within the loop to handle cancellation, preventing potential infinite loops if the context is canceled. This design is appropriate for long-running iterations.
70-78:✅ Verification successful
Confirm correct behavior when
numexceeds array length.
At(i)uses(c.start + i) % c.sizeto cycle through elements, which is expected ifnumis intentionally larger than the underlying array’s length to allow multiple passes. Ensure clients are aware of this cyclical iteration behavior, especially whennumis very large.Run the following script to search the codebase for all calls of
NewCycleand confirm that the usage is intentional whennumexceeds the underlying array’s length:
🏁 Script executed:
#!/bin/bash # Searching the codebase for calls to NewCycle rg -A 3 'NewCycle\('Length of output: 758
Attention: Confirmed cyclical iteration behavior
The index computation
(c.start + i) % c.sizeinAtis working as designed to support iteration when thenumparameter exceeds the underlying array length. Our review of calls toNewCyclein the test files (specifically intests/v2/e2e/hdf5/hdf5.go) confirms that this cyclical approach is an intentional design choice to allow multiple iterations over the collection, even with a very largenum.Please ensure that clients are clearly informed of this behavior when using large iteration counts.
apis/swagger/v1/vald/search.swagger.json (5)
17-18: Enhanced Documentation for/linearsearchEndpointThe updated
"summary"and"description"now provide a detailed overview including status codes and troubleshooting guidelines. Please verify that the markdown line breaks and table formatting are rendered correctly in your API documentation.
116-117: Enhanced Documentation for/linearsearch/multipleEndpointThe summary and description have been reworded to offer concise instructions along with status code details and troubleshooting information. Please ensure that the table formatting is consistent across all endpoints.
149-150: Enhanced Documentation for/searchEndpointThe revamped summary and description effectively outline the endpoint’s behavior and error resolution steps. Verify that the markdown tables and line breaks appear correctly in the rendered documentation.
215-216: Enhanced Documentation for/search/id/multipleEndpointThe summary incorporates markdown emphasis (e.g., 1 request) and clear troubleshooting guidance. Please review that the formatting and consistency of these details match across similar endpoints.
248-249: Enhanced Documentation for/search/multipleEndpointThe updated summary and description provide a comprehensive overview and troubleshooting section for this endpoint. Confirm that the inline notice and table formatting remain consistent and user-friendly across the documentation.
internal/core/algorithm/usearch/usearch_test.go (1)
670-671:✅ Verification successful
Critical Check: Mutex Field Initialization
Across several (mostly commented-out) test functions, the initialization of the
mufield has been changed from a concrete instance (e.g. usingsync.RWMutex{}) tonil. This change is repeated in multiple diff hunks (lines 670–671, 698, 801, 932, 1065, 1097, 1230, 1505, and 1601).Please confirm that:
- None of the code (either in active tests or when these tests are re-enabled) invokes any methods on this
mufield. A nil pointer dereference at runtime could lead to panics if any part of the implementation expects a valid mutex.- If no synchronization is actually required (because, for example, the tests run with single-threaded access or the field is not used), consider either adding a clear comment documenting why a nil value is safe or removing the field entirely to avoid confusion.
Also applies to: 698-698, 801-801, 932-932, 1065-1065, 1097-1097, 1230-1230, 1505-1505, 1601-1601
Based on the search results from the repository, there aren’t any active invocations on the
mufield (e.g. no calls tomu.Lock()/mu.Unlock(), etc.) ininternal/core/algorithm/usearch/usearch_test.goor elsewhere. This suggests that—even though the initialization ofmuhas been changed tonilin multiple places (lines 670–671, 698, 801, 932, 1065, 1097, 1230, 1505, and 1601)—these tests do not currently rely on the mutex for any synchronization.Critical Check: Mutex Field Initialization is Safe
• The change to set
mutonilis safe under the current test conditions since no methods are being invoked on it.
• However, please consider adding a clarifying comment explaining that since tests run with single-threaded access (or the field is simply unused), synchronization is unnecessary. Alternatively, if the mutex is not needed at all, removing the field could help avoid confusion.--- 🏁 Script executed: ```shell #!/bin/bash # Search for any invocations of mu's methods (like Lock, Unlock, RLock, or RUnlock) rg -nE "mu\.(Lock|Unlock|RLock|RUnlock)" .Length of output: 235
Action: Confirm Mutex Field Safety
- Validation: Please manually verify that no part of the code—in active test functions or elsewhere—calls methods on the
mufield (likeLock,Unlock,RLock, orRUnlock). The absence of such invocations is critical because initializingmuasnilcan lead to runtime panics if any method is invoked.- Recommendation: If no synchronization is needed (e.g., tests are single-threaded or the field isn’t used), add a clear comment documenting that a
nilvalue is safe. Alternatively, if the mutex is not required, consider removing the field entirely to avoid future confusion.- Scope: This check applies across all occurrences, including but not limited to lines 670–671, 698, 801, 932, 1065, 1097, 1230, 1505, and 1601 in
internal/core/algorithm/usearch/usearch_test.go.Please review the repository manually alongside the provided search script to ensure safety before merging.
🏁 Script executed:
#!/bin/bash # Re-run a simpler search for explicit literal invocations of mutex methods # This script searches for "mu.Lock", "mu.Unlock", "mu.RLock", and "mu.RUnlock" in the repository. for method in "Lock" "Unlock" "RLock" "RUnlock"; do echo "Searching for 'mu.$method' in repository:" rg -n "mu.$method" . doneLength of output: 29537
Attention: Mutex Field in usearch_test.go Confirmed Safe
After reviewing the repository and specifically checking that no method (such as Lock, Unlock, RLock, or RUnlock) is invoked on the
mufield withininternal/core/algorithm/usearch/usearch_test.go, it appears that the nil initialization is safe for the current test setup. However, since similar patterns exist in multiple diff hunks, please consider one of the following for future clarity:
- Add a brief comment near the
mufield initialization explaining that the tests are single-threaded (or that the mutex is not used), so a nil value is safe.- Alternatively, if synchronization is not needed at all, consider removing the field to avoid any confusion.
dockers/buildkit/Dockerfile (1)
20-21: Ensure Consistent Formatting at File End
The base image declaration remains unchanged. The addition of a newline at the end of the file improves consistency and adheres to POSIX standards.internal/errors/params.go (1)
20-21: Define New Argument Parser Error
The new error variableErrArgumentParserNotFoundis clearly defined using theNewfunction. Please ensure that this error is used consistently in contexts where an argument parser is expected but missing.dockers/buildbase/Dockerfile (1)
1-1: Formatting Update: Trailing Newline Added
The newline added at the end of the file does not affect functionality but ensures proper file formatting.example/client/go.mod.default (1)
3-3: Update Go Version in Module File
The Go version has been updated togo 1.24.2. Verify that this change aligns with all dependency and build configurations across the project.dockers/agent/core/agent/Dockerfile (1)
97-97: Entry Point Formatting Update
TheENTRYPOINTinstruction remains functionally identical; the change is purely a formatting improvement (newline added).charts/vald/values/dev.yaml (1)
49-49: Addition ofenable_statisticsParameter
The new parameter under theagent.ngtsection appears correctly added. Please ensure the consuming components are updated accordingly and that documentation reflects this new configuration option.dockers/index/job/save/Dockerfile (1)
89-89: Job Save Dockerfile ENTRYPOINT Update
The modification at theENTRYPOINTis a benign formatting change (newline added) with no impact on the container’s behavior.dockers/index/operator/Dockerfile (1)
89-89: Index Operator Dockerfile ENTRYPOINT Change
The change reflects only a formatting adjustment to theENTRYPOINTinstruction, with no functional alterations.dockers/manager/index/Dockerfile (1)
89-89: Manager Index Dockerfile ENTRYPOINT Update
The update is purely a formatting change (newline added) for theENTRYPOINTinstruction. It does not affect functionality.internal/backoff/backoff_test.go (1)
63-63: Consistent change to align with error logging phase-outThis change to
errLog: falsealigns with the removal of theWithEnableErrorLog()option from thedefaultOptionsslice in related files, indicating a strategic shift in how error logging is being handled within the backoff implementation.Makefile.d/e2e.mk (1)
22-26: New e2e/v2 target added for the strategic testing frameworkThis new Makefile target properly integrates the V2 strategic testing framework mentioned in the PR objectives. It runs the
TestE2EStrategytest using a dedicated runner function, which complements the existing e2e targets without modifying them.To verify the integration with existing e2e tests, run:
#!/bin/bash # Check if the run-v2-e2e-crud-test function is properly defined elsewhere in the Makefile system fd -t f "\.mk$" --exec grep -l "run-v2-e2e-crud-test" {}dockers/tools/benchmark/operator/Dockerfile (1)
89-90: Added newline at end of fileThis is a minor formatting improvement that ensures the file ends with a newline character, which is considered a best practice in text files to avoid issues with certain tools.
dockers/index/job/readreplica/rotate/Dockerfile (1)
89-90: Added newline at end of fileThis is a minor formatting improvement that ensures the file ends with a newline character, which is considered a best practice in text files to avoid issues with certain tools.
internal/config/benchmark_test.go (2)
22-22: LGTM: Added new Meta field to support metadata in benchmark configurationThe addition of the
Meta map[string]stringfield to thefieldsstruct enables attaching arbitrary metadata to benchmark configurations, which aligns with the E2E testing framework enhancements described in the PR objectives.
49-49: Consistent implementation of Meta fieldThe Meta field has been consistently implemented across all test cases with proper initialization to
nil. This ensures that when these tests are uncommented for implementation, they will be consistent with the updated struct definition.Also applies to: 70-70, 103-103
Makefile.d/tools.mk (3)
216-216: LGTM: Added CMake policy version setting for zlibAdding the
-DCMAKE_POLICY_VERSION_MINIMUM=$(CMAKE_VERSION)ensures that a minimum required CMake policy version is set during zlib configuration, which helps maintain consistent build behavior across different environments.
245-245: LGTM: Added CMake policy version setting for hdf5The same CMake policy version configuration has been consistently applied to the hdf5 build process, maintaining parity with the zlib configuration.
215-227:✅ Verification successful
Verify CMAKE_VERSION variable is defined
Ensure that the
CMAKE_VERSIONvariable is properly defined in the Makefile context before it's used in these commands. If it's not defined, the build might fail with cryptic errors.Also applies to: 244-260
🏁 Script executed:
#!/bin/bash # Check if CMAKE_VERSION is defined in Makefile variables grep -r "CMAKE_VERSION[[:space:]]*[:=]" .Length of output: 160
CMAKE_VERSION is properly defined in the top-level Makefile
Your verification confirms that the
CMAKE_VERSIONvariable is defined as expected:./Makefile:CMAKE_VERSION := $(eval CMAKE_VERSION := $(shell cat versions/CMAKE_VERSION))$(CMAKE_VERSION)Since this definition is available and used consistently (including in the blocks at lines 215-227 and 244-260 of Makefile.d/tools.mk), no further action is needed.
Makefile.d/functions.mk (2)
134-154: LGTM: Added new v2 E2E testing functionThe new
run-v2-e2e-crud-testfunction enhances the testing framework by:
- Providing a cleaner interface for running E2E tests
- Using configuration files instead of numerous individual parameters
- Supporting the new location for v2 E2E tests
This aligns well with the PR objective of creating "a new end-to-end (E2E) testing framework for Vald, focusing on enhancing the maintainability of the testing infrastructure."
Worth noting that this function uses a more maintainable approach by accepting a configuration file (
-config $(E2E_CONFIG)) rather than numerous individual parameters as seen in the original function.
153-153:❓ Verification inconclusive
Verify E2E_CONFIG variable is set correctly
Ensure that the E2E_CONFIG variable is properly defined and points to a valid configuration file, as the entire test depends on this configuration.
🏁 Script executed:
#!/bin/bash # Check for sample E2E configuration files in the repository find ./tests -name "*.yaml" -o -name "*.json" -o -name "*.toml" | grep -i configLength of output: 82
I'll run an additional check to see where and how the E2E_CONFIG variable is defined in the repository, because the original check in the tests folder returned no files. This output may indicate one of two things: either the configuration file is located elsewhere (or has a different naming pattern) or E2E_CONFIG isn’t being set as expected. To further verify, please run the shell script below to search for any assignments or definitions of E2E_CONFIG across the repository:
#!/bin/bash # Search for any assignment of E2E_CONFIG in the repository grep -R "E2E_CONFIG *=" .Based on that additional output, you can confirm if the variable is defined and points to a valid file. If you still see no definition or if its path looks incorrect, a manual review of the configuration management (including CI/CD scripts or Makefiles, such as in
Makefile.d/functions.mk) will be necessary.Rewritten Review Comment:
- Action Required: Verify that the E2E_CONFIG variable is correctly defined.
- Steps to Follow:
- Check that E2E_CONFIG is assigned to a valid configuration file by searching for its assignment in the repository (for example, using the command provided above).
- If the configuration file is located in a different directory or has an unexpected naming scheme, update the Makefile accordingly so that the
-config $(E2E_CONFIG)reference is valid.- Perform a manual verification if these commands do not return the expected assignment.
Makefile.d/minikube.mk (1)
28-29: LGTM: Improved minikube driver configurationThe changes explicitly set and use Docker as the minikube driver, which provides several benefits:
- Ensures consistent behavior across different environments
- Avoids potential issues with the default driver selection
- Makes the configuration more explicit and maintainable
This change likely supports the CI/CD workflow updates mentioned in the PR objectives.
k8s/agent/ngt/configmap.yaml (1)
257-257: Configuration change: Statistics collection is now enabledThe change from
enable_statistics: falsetoenable_statistics: truewill activate metrics collection in the NGT component. This might impact performance and resource usage, but will provide valuable data for monitoring and the new E2E testing framework.Consider documenting this behavioral change and verifying that the system has adequate resources to handle the additional overhead of statistics collection.
internal/runner/runner.go (1)
180-220: Improved error handling witherrors.IsNotfunctionThe refactoring of multiple error condition checks to use the
errors.IsNotfunction greatly improves code readability and maintainability. This change consistently simplifies error handling across multiple lifecycle phases (pre-stop, stop, post-stop, and wait) by replacing verbose conditions with a more concise approach.-if err != nil && err != context.DeadlineExceeded && err != context.Canceled { +if errors.IsNot(err, context.DeadlineExceeded, context.Canceled) {internal/config/grpc.go (1)
186-186:✅ Verification successful
Function name updated for better semantic clarity
The function name has been updated from
WithOldConnCloseDurationtoWithOldConnCloseDelay, which more accurately reflects its purpose - it sets a delay before closing old connections rather than just setting a duration.The parameter name in
ConnectionPoolstruct (OldConnCloseDuration) has not been updated to match the new function name. Verify if this inconsistency is intentional or if it should be updated for consistency:
🏁 Script executed:
#!/bin/bash # Check if the parameter name is used elsewhere in the codebase grep -r "OldConnCloseDuration" --include="*.go" .Length of output: 849
Approved: Function Name Clarification is Intentional
The update from
WithOldConnCloseDurationtoWithOldConnCloseDelayclearly conveys that the function sets a delay before closing old connections. A repository-wide grep confirms that the parameter nameOldConnCloseDurationis used consistently across several files (e.g., ininternal/config/grpc.go,grpc_test.go,backup_test.go, etc.), which indicates that retaining the original parameter name is an intentional decision for backward compatibility.
- No update to the parameter
OldConnCloseDurationis necessary at this point.- The semantic clarity improvement in the function name is approved as is.
internal/net/grpc/pool/option_test.go (2)
449-525: Variable naming improved in TestWithResolveDNSThe parameter name change from
flgtoenableinTestWithResolveDNSimproves code readability by using a more descriptive name that clearly indicates the boolean parameter's purpose.
872-949: Test function rename matches implementationThe test function name has been updated from
TestWithOldConnCloseDurationtoTestWithOldConnCloseDelayto maintain consistency with the implementation changes in the main code. This ensures that test names accurately reflect the functionality being tested.internal/client/v1/client/discoverer/discover.go (1)
290-294: Improved error handling with errors.IsNotThe change replaces nested
!errors.Is()calls with a singleerrors.IsNot()call, which makes the code more concise and readable while maintaining the same behavior.internal/net/grpc/pool/pool_bench_test.go (2)
120-125: Using b.Loop() improves benchmark implementationReplacing the manual
for i := 0; i < b.N; i++loop withb.Loop()is a better practice for Go benchmarks. This approach allows the testing framework to have more control over the benchmark execution.
144-149: Consistent use of b.Loop() in benchmarksGood to see the consistent use of
b.Loop()here as well, maintaining the same benchmark pattern across all tests.internal/timeutil/time.go (3)
19-19: Simplified importsRemoved the unnecessary
errorspackage import which is no longer used after refactoring.
28-28: Simplified error handlingThe code now returns the original error directly instead of wrapping it with additional context. This is cleaner when the original error already contains sufficient information.
47-55:✅ Verification successful
Added useful DurationString type with conversion methods
Good addition of the
DurationStringtype and its methods that provide a more natural way to convert string durations totime.Durationobjects. This makes the API more flexible and intuitive.Let's verify that these new methods are properly tested:
🏁 Script executed:
#!/bin/bash # Check if there are tests for the new DurationString methods rg -A 5 "TestDurationString_Duration|TestDurationString_DurationWithDefault" --glob "*.go"Length of output: 773
Review Comment Update: DurationString Implementation and Tests Verified
The new
DurationStringtype and its conversion methods (DurationandDurationWithDefault) have been confirmed to be well-tested. The tests (TestDurationString_DurationandTestDurationString_DurationWithDefault) ininternal/timeutil/time_test.goverify their functionality, ensuring that the API improvements are robust and reliable.
- Changes verified in:
internal/timeutil/time.go(lines 47-55)- Test coverage confirmed in:
internal/timeutil/time_test.gointernal/servers/server/server.go (2)
461-463: Simplified error condition checking with errors.IsNotReplaced multiple error comparison conditions with a single
errors.IsNot()call, which improves readability while maintaining the same logic. This change makes the code more maintainable.
466-468: Consistent use of errors.IsNot for context errorsGood continuation of the pattern with
errors.IsNot()for context errors as well. This maintains consistency in the error handling approach throughout the codebase.internal/db/nosql/cassandra/option_test.go (1)
538-538: Improved error handling with simplified error constructionThe changes simplify the error handling across multiple test cases by using a more direct approach to error construction. Rather than using
errors.Jointo combine multiple error messages, the code now directly passes the underlying error toerrors.NewErrCriticalOption.This approach results in cleaner, more concise error messages while maintaining the essential error information needed for testing.
Also applies to: 1524-1524, 1616-1616, 1708-1708, 1875-1875, 2980-2980, 3070-3070, 3925-3925
internal/net/net_test.go (1)
314-314:❓ Verification inconclusive
Ensure this change is intentionally classifying "localhost:8080" as IPv6.
The test expectation has been changed to mark "localhost:8080" as IPv6 instead of IPv4. Make sure this aligns with the actual implementation behavior, as localhost is commonly associated with 127.0.0.1 (IPv4), though it could resolve to ::1 (IPv6) as well.
🏁 Script executed:
#!/bin/bash # Check how localhost is being resolved in the actual implementation rg -A 10 -B 10 "Parse" internal/net/net.goLength of output: 2400
Ensure "localhost:8080" is Verified as IPv6
- The test now expects that "localhost:8080" returns
isV6: true.- The implementation in
internal/net/net.gofirst attempts to parse the host as an IP literal and, upon failure (as with "localhost"), falls back to a DNS lookup viaDefaultResolver.LookupIPAddr. In environments where "localhost" resolves to::1, this behavior sets the IPv6 flag.- Action: Confirm that the test environment consistently resolves "localhost" to an IPv6 address. If any environment resolves it to 127.0.0.1 (IPv4), consider adjusting either the test or the DNS resolution behavior to ensure consistent classification across platforms.
pkg/gateway/mirror/service/mirror.go (2)
143-143: Good refactoring to use errors.IsNot helper function.The change from
!errors.Is(err, errors.ErrTargetNotFound)toerrors.IsNot(err, errors.ErrTargetNotFound)improves code readability. This is a positive change that makes the intent clearer.
344-344: Consistent use of errors.IsNot improves code maintainability.Similar to the previous change, using
errors.IsNotinstead of negatingerrors.Iscreates more consistent and readable error handling throughout the codebase.internal/backoff/backoff.go (1)
22-22: Good modernization using maps.Clone for map copying.Using
maps.Clone(metrics)instead of manually creating and populating a new map is a great improvement:
- It's more concise and readable
- It leverages the standard library functionality
- It potentially has better performance characteristics
This change shows good awareness of modern Go practices.
Also applies to: 244-244
internal/config/config_test.go (1)
999-1003: Test case update to correctly handle non-existent files.The test has been appropriately renamed from "return file contents when val is file://env" to "return empty when not exists file contents" and now properly expects empty results when the file doesn't exist. This better reflects the actual behavior when a referenced file is missing.
internal/rand/rand.go (1)
70-76: Improved robustness in seed initializationThe new implementation adds a safety check to ensure the random number generator is never initialized with a zero seed, which could lead to predictable sequences. This is a good defensive programming practice.
internal/config/index_deleter_test.go (1)
16-140: Test function is commented out and not implementedThis test file contains a well-structured test for
IndexDeleter.Bind(), but it's entirely commented out with "NOT IMPLEMENTED BELOW" at the top. The test follows the standard pattern used in the project with fields, expected results, and a test runner, but lacks actual test cases.Since this is part of the new E2E testing framework, having proper test coverage is important. Please implement concrete test cases or consider removing this file if it's not needed yet. Without active test cases, there's no test coverage for the
IndexDeleter.Bind()method.apis/swagger/v1/vald/flush.swagger.json (1)
17-17: Improved API documentation with status codesThe expanded summary provides much clearer documentation for the Flush RPC endpoint. The addition of the status code table is particularly helpful for API consumers to understand possible responses.
internal/net/http/client/option_test.go (1)
260-260: LGTM! Simplified error handling is more readable.The simplification of error messages by removing the unnecessary
errors.Joinand keeping only the direct error message provides cleaner and more readable test code. This consistent change across all timeout-related tests improves maintainability.Also applies to: 769-769, 866-866, 963-963
internal/net/dialer_test.go (1)
1993-2079: Implement the commentedTest_isQUICDialfunction.The
Test_isQUICDialfunction is still commented out and contains only placeholder code with TODOs. This test won't be executed and doesn't contribute to code coverage.Following the previous review suggestion, please implement test cases for both QUIC and non-QUIC network types, various address formats, and edge cases.
internal/errors/errors.go (2)
170-180: LGTM! TheIsAnyimplementation is clean and efficientThe function correctly checks if an error matches any of the target errors, with appropriate handling for nil errors and empty target lists.
182-192: LGTM! TheIsNotimplementation is consistent with other error checking functionsThe implementation correctly checks if an error doesn't match any target errors and has proper nil handling.
internal/servers/servers.go (3)
100-100: Nice simplification of error checking usingIsNotThe code now uses the new
errors.IsNotfunction instead of multipleerrors.Ischecks, which improves readability and maintainability.
123-123: Good use ofIsNotfor error comparisonThis simplifies the error check for non-server-closed errors, making the code more readable.
132-132: Consistent error handling withIsNotThe use of
errors.IsNothere maintains consistency with the earlier error check in the same function.internal/net/http/client/client.go (3)
37-38: Good refactoring: New function now calls specialized implementation.The
Newfunction has been refactored to call the newly introducedNewWithTransport, which improves code organization by reducing duplication.
40-50: Well-designed API extension with proper fallbacks.The new
NewWithTransportfunction enhances flexibility by allowing callers to specify a custom transport while maintaining backward compatibility. The implementation correctly:
- Handles the case when the provided RoundTripper is not of type
*http.Transport- Provides a proper fallback to the default transport
- Includes clear documentation
This is a good example of extending an API without breaking existing code.
63-65: Improved variable declaration for better readability.Explicitly declaring the
errvariable before assignment improves code clarity. This makes the error handling pattern more consistent with other parts of the codebase.internal/net/grpc/client.go (9)
173-184: Good improvement: Simplified error checking witherrors.IsNot.Replacing multiple
!errors.Is()checks with a singleerrors.IsNot()call makes the code more readable and maintainable. This change maintains the same logic while reducing visual clutter.
261-269: Consistent error handling pattern applied.Good use of the same
errors.IsNot()pattern for checking multiple error conditions. This creates consistency across the codebase and makes the error handling logic easier to follow.
299-307: Maintained consistency in error handling refactoring.The refactoring to use
errors.IsNot()is consistently applied across the file, showing a systematic approach to code improvement. This reduces technical debt by standardizing error handling patterns.
374-382: Simplified error check for disconnecting unhealthy connections.Using
errors.IsNot()for checking error conditions when disconnecting continues the pattern of code improvement. The consistent application of this pattern throughout the file is commendable.
480-506: Well-applied error handling in RangeConcurrent.The use of
errors.IsAny()to check for context cancellation or deadline exceeded improves code readability and maintains the same logical flow. This is a good example of how the new error utilities can simplify complex conditions.
753-768: Improved error handling in RoundRobin function.The refactoring in this section effectively applies the
errors.IsAny()pattern to simplify what would otherwise be a series oferrors.Is()checks. This maintains consistent error handling throughout the codebase.
853-868: Consistent pattern in connectWithBackoff.The refactoring continues to maintain consistency in the
connectWithBackoffmethod, usingerrors.IsAny()to check for various error conditions. This systematic approach to error handling creates a more maintainable codebase.
888-894: Final application of the error handling pattern.The last instance of the error handling refactoring in this file follows the same pattern, completing a comprehensive improvement to error handling throughout the file.
983-986: Simplified error checking with errors.IsNot in Connect and Close methods.The refactoring of error handling in these methods is consistent with the changes throughout the file. Using
errors.IsNot()for single error checks simplifies the code compared to negatederrors.Is()checks.Also applies to: 994-997, 1090-1092
internal/net/grpc/errdetails/errdetails.go (4)
26-36: Updated imports for enhanced functionality.The addition of
internal/convimport and switch to usingprotojsonpackage from Google's Protobuf library improves the encoding capabilities of this file.
80-82: Good addition: New Details struct type.The new
Detailsstruct provides a cleaner way to represent multiple error details, improving the structure for JSON serialization and error handling.
315-323: Enhanced Serialize function with better handling of multiple messages.The updated
Serializefunction now uses the newDetailsstruct for marshaling multiple messages and performs a nil check on the byte slice before returning results. The use ofconv.Btoainstead of direct string conversion is also a good practice.
330-331: Improved AnyToErrorDetail with fallback support.The changes to the
AnyToErrorDetailfunction include:
- Better type name handling with prefix trimming (similar to MarshalJSON)
- Addition of a default case that attempts to unmarshal unknown types
- Enhanced error logging that includes the type name
These improvements make error handling more robust when dealing with unknown types.
Also applies to: 416-425
internal/file/file.go (3)
259-264: Simplified error handling using errors.IsNot.The change from
if err != nil && !errors.Is(err, io.EOF)toif errors.IsNot(err, io.EOF)makes the code more concise and readable while maintaining the same logic. This is a good application of the new error handling utilities.
374-391: Well-designed AbsolutePath function with comprehensive edge case handling.The new
AbsolutePathfunction is a good addition that encapsulates path normalization logic. It correctly handles:
- Empty path checks
- Relative to absolute path conversion
- Current working directory fallbacks
- Path normalization using filepath.Clean
This refactoring improves code modularity and makes path handling more maintainable.
564-565: Simplified Join function by leveraging the new AbsolutePath.The
Joinfunction now delegates path normalization toAbsolutePath, which improves separation of concerns and makes the code more maintainable.pkg/agent/core/faiss/service/faiss.go (3)
1125-1128: Good refactoring of error checking inCreateAndSaveIndexThe use of
errors.IsNotsimplifies the code by consolidating multiple error checks into a single function call, making the error handling more concise and readable.
1260-1266: Consistent error handling improvementThe use of
errors.IsNotfor error checking is consistent with the changes in other parts of the file and provides a more concise way to handle multiple error conditions.
1268-1274: Consistent error handling improvementThe error handling is consistent with the changes in other parts of the file, using
errors.IsNotto check against multiple error conditions in a single call.internal/net/http/client/client_test.go (2)
133-136: Good simplification of test setupReplacing the direct client construction with a call to
New()simplifies the test and makes it more maintainable. This approach better isolates the test from implementation details.
149-152: Good simplification of test setupSimilar to the previous case, using
New()simplifies the test setup and makes it more robust against implementation changes in client initialization.internal/test/mock/server_stream.go (2)
31-38: Good defensive programming inSendmethodThe added nil checks and fallback behavior make the
Sendmethod more robust by preventing potential nil pointer dereferences and providing appropriate fallback behavior when function pointers are nil.
40-53: Improved error handling inRecvmethodThe rewritten
Recvmethod now includes proper nil checks, object initialization, and error handling, making it more robust and easier to use. The fallback toServerStream.RecvMsgwhenRecvFuncis nil provides consistent behavior.internal/net/grpc/server_test.go (1)
29-29: Added proto encoding support for gRPC tests.The blank import
_ "google.golang.org/grpc/encoding/proto"is added to ensure the proto encoding format is registered for gRPC tests, which allows for proper serialization/deserialization during testing.internal/params/option.go (4)
20-23: Added imports for OS and filepath operations.These imports support the enhanced default parser configuration that automatically uses the executable name.
27-36: Enhanced default parser configuration with automatic name detection.Setting the parser name to the executable name by default (
filepath.Base(os.Args[0])) is a good practice as it allows for more meaningful help output and error messages without requiring explicit configuration.
89-94: Added option to override default flags.The
WithOverrideDefaultfunction allows controlling whether the defaultflag.CommandLineshould be overridden, providing more flexibility in CLI argument handling.
96-109: Added support for argument filtering.The
WithArgumentFiltersfunction enhances flexibility by allowing clients to filter out specific arguments before they're processed. The implementation is well-structured with proper nil checks and early returns for efficiency.This is particularly useful for E2E testing scenarios where environment-specific arguments need to be filtered out.
internal/info/info_test.go (1)
341-342: Added valdReplacer field to info struct tests.A new
*strings.Replacerfield has been added to theinfostruct test fixtures. This reflects changes to the underlyinginfostruct implementation, which now includes string replacement capabilities, likely for formatting or sanitizing information output.Also applies to: 427-429, 592-594, 682-684, 783-785, 883-885
internal/sync/errgroup/group_test.go (3)
946-953: Updated test structure for atomic operations and function name changeThe test function was renamed from
Test_group_TryGotoTest_group_execto reflect changes in the implementation. Thelimitfield is now usingatomic.Int64instead of a regular variable, which is good for thread safety in concurrent operations.
958-968: Simplified return structure and check functionThe test structure was simplified by removing the
want boolfield and updating the check function signature to match. This suggests the function being tested has a different return signature now, requiring only thewantparameter.
1051-1052: Updated function call to match new implementationThe function call was changed from
g.TryGo(test.args.f)tog.exec(test.args.f), matching the new implementation name. The check function now only expects the test.want parameter, consistent with earlier changes.internal/net/quic/listener_test.go (2)
1-14: LGTM: License and copyright headersThe copyright and license headers follow the project standards.
16-17: Test placeholder setupThe comment "NOT IMPLEMENTED BELOW" clearly indicates this file contains test skeletons for future implementation.
internal/net/grpc/stream_test.go (4)
206-210: Updated args structure for BidirectionalStreamClient testThe
argsstructure was updated to reflect changes in the function signature, replacing the generic data provider and callback functions with more specific typed versions and adding a concurrency parameter.
235-238: Updated test case template with new parameter structureThe test case template was updated to match the new parameter structure, ensuring consistency.
257-260: Updated second test case templateThe second test case template was also updated to match the new parameter structure, maintaining consistency throughout the file.
290-290: Updated function call to match new signatureThe function call to
BidirectionalStreamClientwas updated to use the new parameter structure, ensuring that the test will work properly when implemented.internal/test/data/vector/noise/option.go (3)
17-19: LGTM: Clear package documentationThe package documentation clearly explains the purpose of the noise package.
24-26: Well-defined functional option patternThe code correctly implements the functional option pattern, which is a good practice for configurable components.
28-35: Sensible default options configurationThe default options provide reasonable starting values for the noise generator. The comments clearly explain the purpose of each option.
pkg/index/job/deletion/service/options_test.go (1)
1-14: Good use of proper licensing headers and package declaration.The file includes a standard Apache 2.0 license header and appropriate package declaration, which matches the project conventions.
internal/client/v1/client/discoverer/discover_test.go (1)
132-157: Concurrent Access Test VerificationThe
Test_client_GetReadClient_concurrentfunction tests the atomic behavior under concurrency. The expected final value of the round‑robin counter is verified to be 49. This likely results from a modulo operation that uses(replicas + 1)as the modulus (with replicas set to 100, then 150 % 101 = 49).
- It is worth double-checking that this arithmetic aligns with design intent.
- Verify that all concurrent increments are safe and that the counter is not subject to off‑by‑one issues.
pkg/gateway/lb/handler/grpc/handler_test.go (4)
804-807: Added wantAttrs field enhances test coverageThe addition of
wantAttrs []attribute.KeyValueto thewantstruct improves test coverage by enabling verification of attributes returned from thedoSearchmethod.
814-814: checkFunc signature update properly handles new attribute testingThe function signature has been correctly updated to accommodate the new attribute verification capability.
818-827: Enhanced defaultCheckFunc adds attribute verificationThe defaultCheckFunc has been properly extended to verify the new wantAttrs field, maintaining consistency with the existing error and response verification patterns.
923-924: Updated doSearch invocation captures and validates attributesThe test now correctly captures and passes the new attribute values to the checkFunc, completing the implementation of attribute verification.
internal/config/config.go (2)
66-94: Consider enforcing pointer types forcfg.
By allowing any typeTwithout enforcing it be a pointer, calls toyaml.Unmarshalorjson.Decodemight fail at runtime if a non-pointer is passed. One approach is to add a constraint likefunc Read[T any](path string, cfg *T) erroror enforceTis a pointer type, ensuring configuration fields are actually unmarshaled.Would you like a verification script to see all call sites of
Readand confirm they pass pointers?
128-130: Generic helper function looks good.
ThecheckPrefixAndSuffix[T ~string]function cleanly uses generics and is straightforward. No issues flagged here.internal/params/params.go (8)
29-29: Public alias for flag.ErrorHandling is fine.
This helpful rename can improve code readability, especially if multiple error-handling strategies are used. No immediate concerns.
31-35: Constants effectively mirrorflagerror handling.
Defining local constants forContinueOnError,PanicOnError, andExitOnErroris clear and consistent. Looks good.
69-69: ErrorHandler field usage.
EnsureErrorHandleris set appropriately when creating the parser to avoid unexpected parse behavior. Looks reasonable as is.
88-90: Good defensive check.
ReturningErrArgumentParserNotFoundifp == nilorp.f == nilprevents panics later. Straightforward safeguard.
109-118: Filters with slices.DeleteFunc appear correct.
This approach cleanly removes unwanted arguments. Check if custom logging or user feedback is needed for filtered args. Otherwise, looks good.
120-120: No concerns with parsing arguments.
The error handling is handled below, so everything looks standard.
128-128: Ensuring absolute path is helpful.
Storing configuration paths in absolute form can prevent confusion with relative paths at runtime. Good approach.
131-132: Usage prompt ensures user feedback.
Invokingp.f.Usage()if no config file is found is user-friendly. No further concerns here.apis/swagger/v1/vald/upsert.swagger.json (2)
17-18: Documentation enhancements look great.Adding a structured status code table and troubleshooting section significantly improves clarity for the
/upsertendpoint.
50-51: MultiUpsert documentation improvement recognized.Including the notice for potential gRPC message size limitations alongside detailed status codes and troubleshooting steps is very informative.
internal/net/grpc/stream.go (8)
31-31: No issues with adding this import.
43-53: Nice addition of typed gRPC stream interfaces.Defining generic typed streams for client and server usage strengthens type-safety and clarifies message handling.
60-62: Check the usage of generic constraints.Using
proto.Messageas a constraint ensures that only valid Protobuf messages flow throughBidirectionalStream. This significantly enhances type safety.
106-116: Error handling enhancement on receive.Conditionally distinguishing
io.EOFfrom actual errors helps avoid mistreating normal stream closure as an error. This is a solid approach.
117-167: Effective concurrency handling and tracing.Enlisting an errgroup with controlled concurrency and capturing errors individually provides robust resilience. Locking around
Send()prevents data races on the shared stream.
173-179: Adoption of generics for client streaming.Using
proto.Messageand concurrency limits inBidirectionalStreamClientaligns well with the server-side method. It maintains consistency in how messages are processed.
186-192: Client receive loop reliability.Exiting cleanly on
io.EOF,context.Canceled, orcontext.DeadlineExceededavoids hanging and ensures correct stream termination.
207-257: Refined finalization logic for message sending.Employing a dedicated error channel and a finalize routine to aggregate any send errors is a robust way to manage both partial sends and errors gracefully.
apis/swagger/v1/vald/insert.swagger.json (1)
50-51: Documentation changes look good.
The addition of the status code table and troubleshooting guidelines forMultiInsertsignificantly clarifies potential user issues.internal/net/grpc/pool/option.go (10)
22-22: Import usage acknowledged.
Bringing ininternal/netfornet.SplitHostPortis appropriate for consistent internal utilities. No issues here.
27-27: Doc comment clarity is fine.
Renaming or clarifying the purpose ofOptionis minimal but enhances readability.
30-30: Set default old connection close delay cautiously.
IncludingWithOldConnCloseDelay("2m")in default options is fine, but please verify that 2 minutes is a suitable default. Prolonged retention might hold resources unnecessarily if a different operational context requires quicker cleanup.Also applies to: 37-37
56-63: Host assignment logic is straightforward.
Skipping empty cases and assigning otherwise is clear and aligns with the style in other functions.
65-90: Port configuration logic verified.
BothWithPort,WithStartPort, andWithEndPortensure only valid nonzero (positive) ports are used. No concerns.
92-98: Improved parameter naming.
Changing from a generic flag toenablemakes the code more readable. No additional concerns.
108-116: Atomic assignment for pool size is appropriate.
Usingp.poolSize.Store(size)ensures concurrency safety. Implementation is straightforward.
127-137: Dial timeout behavior is correct.
Parsing the duration and applying it if valid is consistent with other option patterns.
139-150: Old connection close delay logic is consistent.
Mirroring the dial timeout parsing approach is good. No issues found.
151-158: ErrGroup injection is valid.
Allows advanced users to manage concurrency externally. Functionality is straightforward.internal/sync/errgroup/group.go (17)
17-18: Enhanced package documentation is helpful.
It clarifies how this custom errgroup differs from the standard library, improving discoverability.
24-24: Atomic usage recognized.
Importingsync/atomicsuggests concurrency-limited tasks. This approach helps maintain a dynamic limit.
31-42: Interface documentation solid.
The expansions clearly outline the concurrency model (inline vs. goroutine) and error handling approach.
44-60: Struct-level concurrency fields are well-defined.
Fields likelimit,sem, andcancelOnceillustrate a robust concurrency structure.
67-75: New group creation logic is appropriate.
context.WithCancelCauseensures the group can store the root cause of cancellation.
77-82:WithContextdelegating toNewis acceptable.
Keeps the code DRY and consistent, no concerns.
84-91: Global initialization approach is straightforward.
Initensures a single global instance is created on demand, matches the pattern used throughout.
93-99: GlobalGetroutine is correct.
Falls back toInitwith a background context if not yet instantiated.
101-115: Package-level helpers align with concurrency usage.
GoandTryGoforwarding to the global instance is consistent with the library's style.
117-131: Adaptive concurrency limit can be useful.
Settinglimit < 0means no limit, otherwise a semaphore is dynamically resized. As the doc warns, do not modify midflight.
133-162: Inline vs asynchronous execution is a valuable optimization.
execruns tasks synchronously whenlimit == 1, avoiding goroutine overhead. Implementation looks clean.
163-188:Gomethod logic.
Acquires semaphore before spawning a goroutine if concurrency > 1; otherwise executes inline. Well-structured.
189-202:TryGonon-blocking approach is clear.
Gracefully declines new tasks if the semaphore is saturated. This is a nice addition.
217-223:done()gracefully releases resources.
Releases the semaphore slot and decrements wait group—straightforward.
225-233:doCancel()ensures single cancellation.
cancelOnce.Dois the right pattern to avoid repeated cancellations.
235-251:Wait()merges all errors.
Cancels the context at the end, returning the first error or joined errors. Very close to standarderrgroupstyle.
253-260: Package-levelWait()consistent.
Returns quickly if instance is nil, otherwise delegates to the group’sWait(). No concerns.Makefile (9)
163-163: Linker Flags Update: New Optimization Settings
TheLDFLAGSvariable has been updated to use-O3(with-ffast-mathand other optimizations) instead of the previous-Ofaststrategy. Please verify that these optimization flags meet your performance and numerical precision requirements across different platforms.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
167-167: HDF5 Linker Flags Enhancement
TheHDF5_LDFLAGSnow include-lmat the end, ensuring that the math library is properly linked when building HDF5 components. This change appears consistent with the intended adjustments for improved library support.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
169-169: Test Linker Flags Consolidation
TheTEST_LDFLAGSnow consolidate$(LDFLAGS)and$(CGO_LDFLAGS)rather than explicitly combining FAISS and HDF5 flags. Please confirm that$(CGO_LDFLAGS)fully subsumes the required flags for both FAISS and HDF5 components.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
355-356: E2E Testing Configuration Variables Introduced
New variablesE2E_CONFIGandE2E_ADDRhave been added to define the configuration file path and network address for end-to-end tests. Ensure these defaults align with your testing environments and that related documentation is updated to reflect these parameters.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
470-476: .gitfiles Update Logic Revision
Thefilestarget now checks for the existence of a.gitfilesfile and either creates it with 15 empty lines or updates it by preserving the first 15 lines before appending the output fromgit ls-files. Verify that this approach meets your intended caching or file listing requirements and that the default content generated byprintf '\n%.0s' {1..15}does not lead to unexpected behavior.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
552-562: Go Formatting Target Adjustments
In theformat/gotarget, the formatting commands have been restructured to include an installation step forgoimportsalong with a clear output message. The sequence—runninggolines,strictgoimports,goimports,crlfmt, andgofumptsequentially—is intended to enforce a standardized code style. Please review the order and ensure that these tools work harmoniously without redundant processing or conflicts.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
702-703: NGT CMake Policy Flag Addition
The NGT installation command now includes the flag-DCMAKE_POLICY_VERSION_MINIMUM=$(CMAKE_VERSION). This ensures that CMake enforces policies consistent with the specified version, thereby stabilizing the build process for NGT.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
724-725: Faiss CMake Policy Flag Addition
Similarly, the Faiss installation section has been updated to include-DCMAKE_POLICY_VERSION_MINIMUM=$(CMAKE_VERSION). This change promotes uniformity in your CMake configurations across different components.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
748-749: Usearch CMake Policy Flag Addition
The usearch installation now incorporates the flag-DCMAKE_POLICY_VERSION_MINIMUM=$(CMAKE_VERSION). This update should help maintain consistency and compatibility with the project's CMake version settings when building usearch.🧰 Tools
🪛 GitHub Actions: Run unit tests
[error] make: *** [Makefile.d/test.mk:163: test/cmd/gotestfmt] Error 1
.gitfiles (8)
126-126: Build system enhancement with Rust test workflow.Adding a dedicated workflow for Rust unit tests is a great addition that will enhance the CI pipeline for the project's Rust components. This complements the existing unit testing workflow and improves the polyglot nature of the codebase.
161-177: Documentation improvement with structured API templates.The addition of these documentation templates and files will significantly improve the API documentation system. The structured approach with separate files for different operations (filter, flush, index, etc.) makes the documentation more maintainable and easier to navigate.
488-488: Added configuration for the new QBG algorithm.This sample YAML file adds support for configuring the new QBG agent component, which expands Vald's vector search capabilities with a new algorithm implementation.
512-512: Improved test coverage for index deletion operations.Adding test coverage for the index deletion functionality is critical for ensuring the reliability of this important data management operation. These tests complement the implementation of the index deleter component.
Also applies to: 825-832
1051-1051: Core infrastructure enhancements with new abstractions.The addition of params error handling and iterator abstractions aligns with the PR objectives of improving error handling and providing better abstraction layers. These components will enhance code maintainability and reusability across the codebase.
Also applies to: 1088-1088
1407-1410: Testing enhancement with vector noise generation.The vector noise generation functionality will be valuable for creating diverse test datasets and simulating real-world data variations, improving the robustness of your vector search algorithms against noisy data.
2035-2055: Comprehensive E2E testing framework added.This is a major enhancement that directly addresses a key PR objective. The new end-to-end testing framework provides a structured approach with:
- Configurable operations for strategic testing
- Dataset handling capabilities
- Kubernetes integration and port forwarding
- Support for both unary and streaming CRUD operations
- Multi-deployment configuration support
This framework will significantly improve test maintainability and coverage, allowing for more comprehensive validation of the system's behavior in realistic scenarios.
2067-2067: Updated K3D version for containerized Kubernetes testing.Keeping infrastructure tool versions updated ensures compatibility with the latest features and security patches. This K3D version update will support the enhanced E2E testing framework.
hack/go.mod.default (3)
3-3: Go version update looks good.Updating to Go 1.24.2 is appropriate as it likely contains bug fixes and security improvements over 1.24.0.
332-337:✅ Verification successful
Kubernetes dependency updates are appropriate.
The updates to Kubernetes-related dependencies are good practices:
- k8s.io packages updated from v0.32.0 to v0.32.3 (minor version with likely bug fixes)
- sigs.k8s.io/controller-runtime updated from v0.19.3 to v0.20.4 (more significant update)
- sigs.k8s.io/structured-merge-diff/v4 updated from v4.5.0 to v4.6.0
These updates should improve compatibility with the new E2E testing framework mentioned in the PR objectives.
Also applies to: 340-341, 344-344, 347-347
🏁 Script executed:
#!/bin/bash # Check for potential breaking changes in controller-runtime update echo "Checking controller-runtime changelog between v0.19.3 and v0.20.4:" curl -s "https://raw.githubusercontent.com/kubernetes-sigs/controller-runtime/master/CHANGELOG/CHANGELOG-0.20.md" | grep -A 50 "v0.20" | head -30Length of output: 286
Approved: Kubernetes Dependency Updates Validated
The dependency updates in
hack/go.mod.defaultare appropriate. The minor version bumps for thek8s.iopackages (v0.32.0 to v0.32.3) and the update forsigs.k8s.io/controller-runtime(v0.19.3 to v0.20.4) have been verified. A check of the controller-runtime changelog did not surface any breaking changes, and the corresponding update forsigs.k8s.io/structured-merge-diff/v4(v4.5.0 to v4.6.0) aligns with best practices. This set of updates should ensure improved compatibility with the new E2E testing framework.
- Confirmation of changes in
hack/go.mod.default:
- Lines 332-337: Updated Kubernetes dependencies.
- Related updates also verified in lines 340-341, 344-344, 347-347.
16-16:❓ Verification inconclusive
Switching to upgrade directives provides flexibility.
Changing specific versions to
upgradedirectives forcloud.google.com/go/storageandgithub.com/goccy/go-jsonwill allow automatically using the latest compatible versions during dependency resolution.Make sure these dependencies don't have breaking changes in their recent versions:
Also applies to: 134-134
🏁 Script executed:
#!/bin/bash # Check latest versions and recent changes of affected dependencies echo "Checking cloud.google.com/go/storage:" curl -s "https://api.github.com/repos/googleapis/google-cloud-go/releases" | jq -r '.[] | select(.name | contains("storage")) | {name, published_at, body}' | head -15 echo "Checking github.com/goccy/go-json:" curl -s "https://api.github.com/repos/goccy/go-json/releases" | jq -r '.[] | {tag_name, published_at, body}' | head -15Length of output: 2560
Dependency Upgrade Verification
For files
hack/go.mod.default(lines 16 and 134), switching toupgradedirectives is intended to provide flexibility by automatically picking up the latest compatible versions. Our checks on thegithub.com/goccy/go-jsonreleases (v0.10.5, v0.10.4, and v0.10.3) show bug fixes and improvements without any obvious breaking changes. However, the filter applied forcloud.google.com/go/storagedid not return release notes specifically mentioning "storage," so please review the upstream release details for the Google Cloud Go repository manually to ensure that no breaking changes affect the storage client.
- File:
hack/go.mod.default
- Line 16 & 134:
cloud.google.com/go/storage => cloud.google.com/go/storage upgradeapis/docs/v1/docs.md (3)
1676-1677: Flush Service Overview Update
The new "Overview" statement for the Flush service succinctly explains that it is responsible for removing all vectors that are indexed and uncommitted in thevald-agent. This description is clear and consistent with the style used in other sections.
1747-1748: Object Service Overview Addition
The new "Overview" section for the Object service clearly outlines its responsibility for retrieving vectors and checking whether they have been inserted into thevald-agent. This addition improves the readability of the documentation.
1940-1941: Upsert Service Overview Addition
The added overview for the Upsert service effectively communicates that it is responsible for updating existing vectors or inserting new ones into thevald-agentif they do not already exist. This inclusion enhances the documentation’s consistency and clarity across service descriptions.example/client/go.mod (3)
3-3: Bump in Go version.The Go version has been updated from 1.24.0 to 1.24.2. This is typically a minor revision fix, but please ensure the new version is consistently used in your CI/CD and testing environments to avoid potential version mismatches.
10-18: Dependency versions updated.You’ve bumped or replaced multiple dependencies (e.g.,
github.com/pkg/sftp,golang.org/x/crypto,google.golang.org/grpc, etc.). This looks fine for keeping up-to-date. However, please verify these updates do not break existing compatibility or introduce regressions in code paths that rely on older versions.
36-41: Indirect dependencies update.The indirect dependencies (e.g.,
golang.org/x/net v0.37.0 → v0.38.0, google.golang.org/protobuf v1.36.6, etc.) appear consistent with the direct dependencies upgrades. Ensure the updated transitive dependencies align with your semantic version constraints and do not introduce subtle breakage.apis/swagger/v1/vald/update.swagger.json (3)
17-18: Enhanced summary and description for /update endpoint.Providing explicit status codes and troubleshooting information in the summary/description is helpful. This improves clarity for API consumers. Good job including actionable details for each error case.
50-51: Comprehensive documentation for MultiUpdate endpoint.Similar to
/update, the enriched summary and extended troubleshooting guidance for/update/multipleare well-structured. This should lessen user confusion, especially regarding message size limits.
83-83: Incomplete documentation for /update/timestamp.A past review comment already flagged the missing status code and troubleshooting details for this endpoint. Since the summary still uses "TODO", the concern remains.
apis/swagger/v1/vald/filter.swagger.json (8)
17-17: Enhanced Documentation for InsertObject Endpoint.
The updated summary now provides a clear overview of theInsertObject RPCwith a neatly formatted status code table, improving the understandability for API consumers.
49-49: Enhanced Documentation for MultiInsertObject Endpoint.
The revised summary for the/insert/object/multipleendpoint now explicitly describes the operation asMultiInsertObject RPCand includes a detailed status code table. This improvement will help users quickly grasp the endpoint functionality.
81-81: Improved Summary for SearchObject Endpoint.
The enhanced summary now clearly states the role of theSearchObject RPCand provides a status code table that aids in setting expectations for responses.
113-113: Refined Documentation for StreamSearchObject Endpoint.
The updated summary now details that the endpoint deals with bidirectional streaming RPC with multi-query support. The inclusion of a status code table and an explanation of independent request/response handling adds helpful context.
145-145: Updated Summary for UpdateObject Endpoint.
The concise summary now clearly identifies the endpoint as handling updates for a single vector, and the status code table is a valuable addition for error-handling clarity.
177-178: Enhanced Documentation for MultiUpdateObject Endpoint.
The new summary and the additional description warning about gRPC message size limitations together provide essential operational details. This helps prevent misuse and alerts developers to potential payload size issues.
210-210: Improved Summary for UpsertObject Endpoint.
The updated summary now elaborates on the dual functionality of the endpoint (updating and adding objects), and the inclusion of a detailed status code table further clarifies expected responses.
242-243: Refined Documentation for MultiUpsertObject Endpoint.
The revised summary along with the descriptive notice regarding gRPC message size limitations significantly improves the endpoint’s documentation. This clear delineation of behavior and constraints will better inform API clients.internal/net/grpc/option_test.go (15)
532-615: Function renamed to better reflect its purposeThe function
TestWithBackoffMaxDelay(previouslyTestWithDialOptions) has been renamed and its parameter type changed from[]grpc.DialOptiontostring. This change better represents the specific functionality being tested - the maximum delay for backoff operations.
617-700: Appropriate function renaming for backoff configuration testsThe function
TestWithBackoffBaseDelay(previouslyTestWithBackoffMaxDelay) has been correctly renamed while maintaining the appropriate parameter type for duration configuration.
702-785: Parameter type change aligns with parameter purposeThe function
TestWithBackoffMultipliernow correctly uses afloat64parameter type instead of a string, which is appropriate for a multiplier value.
787-870: Consistent parameter typing for backoff configurationThe renamed function
TestWithBackoffJittermaintains the correctfloat64parameter type, preserving type consistency for the jitter configuration value.
872-955: Proper duration parameter for timeout testingThe function
TestWithMinConnectTimeoutnow uses a string parameter for duration, which is consistent with other duration-based configurations in the codebase.
957-1040: Function repurposed for error group functionalityThe function
TestWithErrGroupnow correctly tests error group integration with appropriate parameter typeerrgroup.Group, aligning the test with its actual purpose.
1042-1125: Dedicated test for backoff configurationThe function
TestWithBackoffhas been properly defined to test backoff functionality with the appropriatebackoff.Backoffparameter type.
1127-1210: Circuit breaker test properly definedThe function
TestWithCircuitBreakernow correctly tests the circuit breaker integration with the appropriate parameter type, improving test clarity.
1212-1295: Test restructured for call optionsThe function
TestWithCallOptionshas been properly configured to test gRPC call options with the correct[]grpc.CallOptionparameter type.
1297-1380: Content subtype test properly definedThe function
TestWithCallContentSubtypenow correctly tests the content subtype functionality with an appropriate string parameter.
1382-1465: Message size configuration tests properly organizedThe functions for testing message size configurations (
TestWithMaxRecvMsgSize,TestWithMaxSendMsgSize, andTestWithMaxRetryRPCBufferSize) have been appropriately structured with consistent parameter types.Also applies to: 1467-1550, 1552-1635
1637-1721: Wait-for-ready flag test properly definedThe function
TestWithWaitForReadyhas been defined with the appropriate boolean parameter type, correctly reflecting the flag nature of this option.
1722-1805: Dial options test properly structuredThe function
TestWithDialOptionshas been implemented with the correct parameter type[]grpc.DialOptionto test general dial options functionality.
2581-3174: Comprehensive test coverage with new configuration optionsSeveral new test functions have been added to cover additional gRPC client configuration options:
TestWithAuthorityTestWithDisableRetryTestWithIdleTimeoutTestWithMaxCallAttemptsTestWithMaxHeaderListSizeTestWithSharedWriteBufferTestWithUserAgentThese additions enhance test coverage of the gRPC client option functionality.
3261-3344: Clarified naming for connection delay testThe function
TestWithOldConnCloseDelay(previouslyTestWithOldConnCloseDuration) has been renamed for better clarity while maintaining the same functionality.dockers/gateway/filter/Dockerfile (1)
89-90: ENTRYPOINT Formatting Adjustment
The change at theENTRYPOINTinstruction is purely a formatting update (removing an extraneous newline) and maintains the same functionality. This helps ensure consistent appearance across Dockerfiles.dockers/gateway/lb/Dockerfile (1)
89-90: ENTRYPOINT Formatting Consistency
The modification to theENTRYPOINTline (preserving ["/usr/bin/lb"]) is a cosmetic change that aligns with the formatting standards used in other Dockerfiles. No functional changes observed.dockers/agent/core/ngt/Dockerfile (1)
98-99: NGT Dockerfile ENTRYPOINT Update
The slight formatting update to theENTRYPOINTinstruction in this file matches the consistent convention applied across the repository. The functionality remains unchanged.dockers/agent/core/faiss/Dockerfile (1)
99-100: FAISS Dockerfile ENTRYPOINT Consistency
This update aligns theENTRYPOINTinstruction with the formatting modifications seen in other service Dockerfiles. It is a non-functional change that improves consistency.dockers/gateway/mirror/Dockerfile (1)
89-90: Formatting Update on ENTRYPOINT Instruction.
The change at line 89 appears to be a formatting adjustment (e.g., adding a newline) without altering the actual command. No functional impact is expected..github/workflows/_release-pr.yaml (1)
42-47: Enhanced Container Authentication Credentials.
The newly added credentials (lines 44–46) for the container image improve the security of the CI/CD pipeline by leveraging secrets. Ensure that these secrets are managed securely and are not inadvertently exposed in logs.dockers/agent/sidecar/Dockerfile (1)
88-89: Consistent ENTRYPOINT Formatting.
The update at line 88 (ENTRYPOINT ["/usr/bin/sidecar"]) is a non-functional, formatting change. It aligns this Dockerfile with similar ones in the project.dockers/index/job/deletion/Dockerfile (1)
89-90: Reaffirming ENTRYPOINT Configuration.
The change at line 89 reintroduces the ENTRYPOINT ["/usr/bin/index-deletion"] without any modification to the command’s functionality. This maintains consistency with existing Dockerfiles.dockers/example/client/Dockerfile (1)
95-96: ENTRYPOINT Instruction Formatting Adjustment.
The modification at line 95 (ENTRYPOINT ["/usr/bin/client"]) is purely a formatting change (e.g., removal/addition of a newline) and does not affect the container’s runtime behavior..github/workflows/e2e-code-bench-agent.yaml (2)
61-63: Credentials for grpc-sequential Container Added
The newcredentialsconfiguration using GitHub secrets (PACKAGE_USERandPACKAGE_TOKEN) is correctly added to the container block. Please confirm that these secrets are defined in your repository settings and that they are not exposed in logs.
91-93: Credentials for grpc-stream Container Added
Similarly, the credentials for thegrpc-streamcontainer are now properly configured. Ensure that your container environment supports these credential fields and that they remain secure during job execution..github/workflows/unit-test-rust.yaml (1)
44-46: Credentials for Rust Unit Tests Container Added
The addition of acredentialssection in the container configuration is consistent with similar workflow updates. Verify that the secrets (PACKAGE_USERandPACKAGE_TOKEN) are correctly configured, and that the container image requires authentication as expected..github/workflows/fossa.yaml (1)
39-41: Credentials for FOSSA Scan Container Configuration Added
Thecredentialssection with the secret references has been added to thefossa-scanjob’s container configuration. This is a sound approach to ensure secure access if private resources are needed. Double-check that these credentials are indeed required for the task.k8s/gateway/gateway/mirror/deployment.yaml (1)
48-48: Updated ConfigMap Checksum Annotation
The revision of thechecksum/configmapannotation to the new checksum value suggests that the underlying ConfigMap has changed. Make sure that this value exactly reflects the current configuration so that Kubernetes properly triggers a rollout when the ConfigMap is updated..github/workflows/e2e-max-dim.yaml (1)
43-45: Credentials for E2E Max Dimension Insert Job Added
In thee2e-max-dimension-insertjob, the credentials block is now included in the container configuration. This aligns with the standardized approach seen in other workflow files. Please verify that the referenced secrets are accurate and that they facilitate the necessary authentication for container access during the E2E test..github/workflows/reviewdog-k8s.yaml (3)
36-38: Credentials Added for Container Authentication in kubeval-conflint JobThe addition of the
credentialssection using GitHub secrets enhances security by ensuring that the container can authenticate when pulling images or accessing protected resources. Confirm thatsecrets.PACKAGE_USERandsecrets.PACKAGE_TOKENare correctly configured in the repository.
59-61: Added Credentials for kubelinter-k8s-manifests JobThe new authentication fields enable the container running the
kubelinter-k8s-manifestsjob to securely access necessary resources. Verify consistency with other workflows.
81-83: Secure Container Authentication for kubelinter-vald-chart JobIncluding credentials from GitHub secrets in the container configuration improves security and ensures that the job can pull the required container image without issues.
.github/workflows/test-hack.yaml (1)
58-60: Credentials Configured for test-hack Container JobIn this job, adding the
credentialssection withPACKAGE_USERandPACKAGE_TOKENsecures the container’s access to necessary registries. Make sure these secrets are properly maintained..github/workflows/build-protobuf.yaml (1)
43-45: Secure Container Authentication for Build JobThe inclusion of the
credentialsblock in the container configuration ensures authenticated access when pulling the specified container image. This is a good step toward standardizing security across workflows.k8s/index/operator/deployment.yaml (1)
49-49: Updated ConfigMap Checksum AnnotationThe
checksum/configmapannotation has been updated to637fcc0bce34680472bc6c958c48ec9f8eba4680ca0019ec5f01007f6e5a37ea. Please verify that this checksum accurately reflects the updated ConfigMap contents to ensure proper rollout of configuration changes..github/workflows/helm.yaml (2)
38-40: Authentication Credentials Added in Update Helm Chart JobThe new
credentialssection in the container configuration for the update job secures the pull of the container image by using GitHub secrets. Ensure that the secret values are up-to-date and consistent.
84-86: Secure Container Configuration in CRUD Helm Chart JobAdding authentication credentials here reinforces secure access when interacting with remote Helm charts. This change aligns the job with the broader security standard adopted across the workflows.
.github/workflows/e2e-profiling.yaml (1)
45-47: Container Credentials Addition
The newcredentialssection under the container configuration ensures that the workflow can authenticate with the remote container registry using the provided secrets. Please double-check that bothPACKAGE_USERandPACKAGE_TOKENare configured correctly in your repository’s secrets to prevent authentication issues.dockers/ci/base/Dockerfile (1)
130-130: Unchanged ENTRYPOINT Update
The update to theENTRYPOINTline (with the addition of a newline) does not affect the container’s functionality but improves file formatting consistency. Please confirm that this formatting change was intentional..github/workflows/reviewdog.yaml (2)
35-37: Authenticated Container Setup for GolangCI-Lint
Adding thecredentialssection to the container configuration for thegolangci-lintjob is a good move toward securing your CI environment. Ensure that the secrets are correctly set in your repository.
57-59: Authenticated Container Setup for Go Build
The inclusion of container authentication for the go-build job mirrors the approach used for golangci-lint. This helps maintain consistent security practices across your jobs. Please verify that these credentials are valid and up to date..github/workflows/build-binaries.yaml (1)
34-36: Container Authentication Credentials
The newcredentialssection in thebuild-linuxjob enables secure access to the container image by using the provided secrets. It’s important to ensure that these secrets are maintained securely within your CI/CD environment..github/PULL_REQUEST_TEMPLATE.md (1)
19-25: Updated Version Numbers in PR Template
The version numbers for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss have been updated to reflect recent releases. Please ensure these numbers remain consistent with the versions specified in other build configuration files and documentation..github/workflows/coverage.yaml (1)
45-47: Secure Credential Injection in Container
The newly addedcredentialsblock properly injects the container image’s authentication details using GitHub secrets. This is consistent with practices across the repository. Make sure that the repository settings securely manage these secrets..github/workflows/unit-test.yaml (3)
54-56: Credential Addition for test-cmd Job
The newcredentialssection under thecontainerfor thetest-cmdjob is correctly added. It ensures authenticated access to the container image using${{ secrets.PACKAGE_USER }}and${{ secrets.PACKAGE_TOKEN }}.
74-76: Credential Addition for test-internal Job
The credentials provided in thetest-internaljob follow the same secure pattern. This consistency across jobs improves maintainability and security when pulling the container image.
94-96: Credential Addition for test-pkg Job
Similarly, thetest-pkgjob now includes a credentials block that ensures secure container image retrieval. All three test jobs now consistently use the designated GitHub secrets for authentication..github/ISSUE_TEMPLATE/bug_report.md (1)
26-32: Updated Environment Versions in Bug Report Template
The version numbers for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss have been updated to the latest values. This update helps maintain consistency across documentation and ensures users reporting bugs reference current software versions..github/workflows/update-deps.yaml (1)
34-36: Credential Addition in Update-Dependencies Workflow
Adding thecredentialsblock within theupdate-versionjob aligns this workflow with other parts of the repository. This change secures the pull of the container image by using the appropriate GitHub secrets..github/ISSUE_TEMPLATE/security_issue_report.md (1)
20-26: Updated Environment Versions in Security Issue Report Template
The version numbers for Go, Rust, Docker, Kubernetes, Helm, NGT, and Faiss have been revised to the updated releases. This ensures that security reports are made against the current software landscape and are consistent with other issue templates..github/workflows/helm-lint.yaml (3)
35-37: Add container credentials for lint-vald-chart job
The new credential block correctly sources thePACKAGE_USERandPACKAGE_TOKENfor authenticating the container pull. This improves security when accessing private resources.
55-57: Add container credentials for lint-vald-helm-operator-chart job
The added credentials for this job mirror the changes in the previous block. Ensure that the same secret names are configured in your repository.
77-79: Add container credentials for lint-values-schema job
The addition of the credentials block here is consistent with the other lint jobs. No issues are observed; please verify that these secrets are available in all target environments..github/workflows/e2e-chaos.yaml (4)
47-49: Add container credentials for agent-failure job
The new credentials block under theagent-failurejob ensures secure access to the specified container image. This aligns with recent changes across other workflows.
91-93: Add container credentials for random-pod-failure job
Credentials have been added in a similar manner to previous jobs. Double-check that the secrets used here are correctly set up since these jobs run with elevated privileges for chaos testing.
135-137: Add container credentials for agent-network-partition job
Consistently adding the credentials here helps ensure that even in network partition tests, secure container access is maintained.
179-181: Add container credentials for clusterwide-network-bandwidth job
The credentials block inclusion is consistent with the rest of the chaos tests. Ensure that these credential secrets are rotated regularly for security.k8s/manager/index/deployment.yaml (1)
48-50: Update ConfigMap checksum annotation
The checksum annotation has been updated to the new value. Please confirm that this new checksum matches the current contents of the referenced ConfigMap so that the pods will correctly trigger a rolling update..github/workflows/_docker-image.yaml (2)
74-79: Introduce DockerHub login step
A new step to log into DockerHub using thedocker/login-action@v3is added. The credentials (DOCKERHUB_USERandDOCKERHUB_PASS) are now explicitly set, which is helpful for securing the build and publish process.
80-84: Introduce GitHub Container Registry login step
This new step logs into GHCR using the provided secrets. It’s consistent with best practices to authenticate before performing image builds..github/workflows/chatops.yaml (5)
32-34: Add container credentials for label job
The credentials section added for thelabeljob ensures that the container running ChatOps actions authenticates securely with the registry. Everything is set as expected.
85-87: Add container credentials for rebase job
The new credentials block for the rebase job is consistent with the other container configurations. Confirm that these secrets are synchronized across workflows for uniformity.
165-167: Add container credentials for gentest job
The credentials inclusion ensures thegentestjob can securely pull the image. This follows the same structure as in previous jobs.
280-283: Add container credentials for format job
This new credentials block is correctly added for the format job. Consistency across the ChatOps workflows helps maintain secure container access.
415-419: Add container credentials for approve job
The approve job now includes container authentication, securing the operations that post approvals via ChatOps. No concerns noted.k8s/gateway/gateway/lb/deployment.yaml (1)
48-48: ConfigMap checksum updated.The update to the
checksum/configmapannotation reflects changes in the underlying configuration that will be applied to the vald-lb-gateway deployment. This is part of the configuration changes supporting the new E2E testing framework.k8s/discoverer/deployment.yaml (1)
49-49: ConfigMap checksum updated.The update to the
checksum/configmapannotation reflects changes to the vald-discoverer ConfigMap. This ensures that pods will be rolled out with the updated configuration that supports the new E2E testing framework.pkg/agent/core/ngt/service/option_test.go (1)
319-319:✅ Verification successful
Simplified error messages in test cases.
The error handling in test cases for invalid duration strings has been streamlined. Instead of using
errors.Jointo combine multiple error messages, the code now uses a single, more concise error message. This aligns with the broader changes to error handling across the codebase.Verify that this simplified error message matches what is returned by the actual time.ParseDuration function:
Also applies to: 404-404, 489-489, 650-650, 735-735, 820-820, 905-905, 1365-1365
🏁 Script executed:
#!/bin/bash # Verify that the error message in tests matches what time.ParseDuration would return # Look for the actual time.ParseDuration usage and how errors are handled rg "time\.ParseDuration\(" -A 3 --type goLength of output: 3419
Simplified Error Messages Verified
The error message in tests now directly mirrors the output from Go’s
time.ParseDuration. For example, inpkg/agent/core/ngt/service/option_test.goat line 319, the errorerr: errors.New("time: unknown unit \"ss\" in duration \"5ss\""),accurately reflects the error returned by
time.ParseDurationwhen given an invalid duration string. This behavior is consistent across all affected test cases (e.g., lines 404, 489, 650, 735, 820, 905, 1365), aligning with the broader error handling improvements across the codebase.cmd/index/job/deletion/main_test.go (1)
16-86: Address or remove placeholder test codeThis test file contains a completely commented-out test structure with "NOT IMPLEMENTED BELOW" note. Since this appears to be part of the E2E test framework PR, you should either implement the tests or remove the placeholder if not needed immediately.
.github/workflows/format.yaml (2)
36-38: Security improvement through container credential configurationAdding credentials for container image access is a good security practice that ensures only authorized access to the container images.
Also applies to: 95-97
108-109: Enhanced formatting workflow with additional targetsThe updated command now includes license formatting and Go test formatting, making the PR formatter more comprehensive. The additional targets align well with the E2E testing framework improvements in this PR.
internal/test/data/vector/noise/option_test.go (1)
16-271:✅ Verification successful
Test skeletons provided for noise generator options
This file provides comprehensive test structures for the vector noise generation options, which will be useful for the E2E testing framework. However, all tests are currently commented out as placeholders.
🏁 Script executed:
#!/bin/bash # Verify that the actual option.go file has the corresponding functions being tested rg -A 3 "func With(LevelFactor|TableDivisionFactor|MinTableSize)" internal/test/data/vector/noise/option.goLength of output: 446
Verification Complete: Option Function Implementations Confirmed
- The functions
WithLevelFactor,WithTableDivisionFactor, andWithMinTableSizeare correctly implemented ininternal/test/data/vector/noise/option.go, matching the intended usage in the test skeletons.- The test file provides well-structured placeholders for future test cases, which is acceptable given the current focus on establishing the overall test framework.
internal/params/option_test.go (2)
517-517: Parallelized test execution with goroutine leak detectionThe test structure includes parallel test execution (
tt.Parallel()) and goroutine leak detection (goleak.VerifyNone()), which are good testing practices that should be maintained when implementing the actual tests.Also applies to: 602-602, 687-687
451-705:✅ Verification successful
Test skeletons provided for parameter options
This file adds test structures for three new option functions (
WithName,WithOverrideDefault, andWithArgumentFilters), which align with the PR's focus on enhancing the E2E testing framework. However, the tests are currently commented out as placeholders.
🏁 Script executed:
#!/bin/bash # Verify that the corresponding option functions exist in the implementation file rg -A 3 "func With(Name|OverrideDefault|ArgumentFilters)" internal/params/option.goLength of output: 414
Action: Confirm Option Function Implementations and Update Test Placeholder Note
The corresponding option functions (
WithName,WithOverrideDefault, andWithArgumentFilters) have been verified ininternal/params/option.go. The test file still retains the skeleton test cases as commented placeholders. Please confirm if we plan to implement the detailed tests now or in a follow-up PR.pkg/agent/core/ngt/service/ngt_test.go (4)
11045-11047: Good addition of context support to test arguments.Adding context to test arguments is a good practice that allows for better testing of context-aware functions.
11102-11102: Consistent structure update for context handling.The test struct has been appropriately updated to include the args field and modify the function signatures to pass context through the args parameter.
Also applies to: 11106-11107
11174-11177: Helper functions properly updated to accept context.The before and after functions have been correctly updated to accept the args parameter, maintaining consistency with the updated test structure.
Also applies to: 11242-11246
11259-11262: Proper usage of updated function signatures.The calls to beforeFunc and afterFunc have been correctly updated to pass the test.args parameter, ensuring the context is available during setup and teardown.
pkg/agent/core/ngt/service/ngt.go (1)
927-934: Clarify or confirm the intention of ignoring this error.The code branches if
errors.IsNot(err, errors.ErrUncommittedIndexNotFound), marking other error cases to be returned immediately. Ensure it is safe to silently ignoreErrUncommittedIndexNotFoundin this context and verify that no critical scenarios are overlooked.internal/test/data/vector/noise/noise.go (1)
139-168: Ensure thread safety for random noise generation.The current Box-Muller transform logic is fine for single-thread usage. However, if multiple goroutines simultaneously call
New(...), consider concurrency-safety with the shared random source. Use thread-safe random strategies or a locking mechanism if concurrency is expected.internal/params/params_test.go (25)
31-31: Good addition of descriptive comment.Adding descriptive function comments improves code readability and documentation.
47-72: Improved test check function with detailed field validation.The enhanced
defaultCheckFuncnow performs more granular validation by checking individual fields instead of using deep equality. This improves test diagnostics by providing precise error messages when specific fields don't match expectations.
77-78: More descriptive test case name.The updated test name clearly describes the purpose of the test case, which improves readability and understanding.
85-87: Consistent array formatting in test data.The test fixtures now use consistent array formatting in the test data structures, making the code more readable.
Also applies to: 94-97
102-103: Improved test case description.The test name now clearly indicates what's being tested, which helps with understanding the test's purpose.
115-117: Consistent array formatting in test data.Test fixtures consistently format arrays, improving readability.
Also applies to: 124-127
143-146: Simplified check function assignment.This change simplifies the code by directly assigning the check function variable rather than using a conditional statement.
155-156: Enhanced function documentation.Adding descriptive comments for functions improves code readability and documentation.
170-173: Added help flag tracking to want struct.The
wantstruct now includes ahelpboolean field to track whether the help option was triggered, which expands test coverage for different scenarios.
177-177: Improved clarity in test arguments.Renaming the field to
argswith a descriptive comment clarifies that it represents custom command-line arguments.
183-217: Enhanced check function with better error handling.The improved
defaultCheckFuncnow:
- Checks for help flag status
- Handles nil expected data case
- Provides type safety checks
- Offers more detailed error messages for mismatches
This makes test failures more informative and easier to debug.
221-222: More descriptive test case name.Renamed test case for better clarity on what's being tested.
242-252: Improved test setup with temporary file creation.The test now creates a temporary file to ensure the test has valid file path data, enhancing test robustness. The cleanup function properly removes the file after the test, preventing resource leaks.
257-265: Improved test data documentation.Added comments to explain validation approach for config file paths, improving test maintainability.
266-269: Simplified check function with reuse.Delegating to the default check function reduces code duplication and improves maintainability.
272-273: Descriptive test case name.The test case name now clearly describes the scenario being tested: the version flag taking precedence even when file doesn't exist.
309-310: Added test for help flag.New test case to verify help flag handling, improving test coverage.
342-343: Added test case for unknown flags.This new test case verifies proper error handling for unknown command-line flags, improving test coverage for error scenarios.
375-376: Added test for empty config file path handling.This new test case verifies behavior when config file path is empty, improving test coverage.
423-426: Updated Parse method signature in tests.The test now correctly expects three return values from the Parse method, aligning with the implementation.
437-438: Improved function documentation.Adding clear descriptive comments for methods enhances code readability and documentation.
Also applies to: 495-496
454-456: Improved error message format.The error messages now show both expected and actual values, making it easier to diagnose test failures.
Also applies to: 512-514
527-535: Added test case for negative scenario.This additional test case verifies the ShowVersion method returns false when appropriate, improving test coverage.
551-556: Consistent error handling pattern.The test now uses a consistent pattern for error handling across test cases, improving code maintainability.
563-681: Commented out unimplemented tests with proper formatting.The commented-out test stubs are properly formatted as comments, preventing compilation errors while keeping placeholders for future implementation.
.github/workflows/codeql-analysis.yml (4)
46-68: Enhanced CodeQL workflow with language-specific configuration.The updated workflow now uses a matrix strategy to run CodeQL analysis on multiple languages (actions, go, rust) with appropriate build modes for each. The job configuration also:
- Dynamically selects the runner OS based on language requirements
- Sets proper permissions for security events and resource access
- Enables experimental features for CodeQL
- Uses a fail-fast: false strategy to ensure all language analyses run even if one fails
This approach is more maintainable and flexible than the previous single-language configuration.
84-88: Updated CodeQL initialization with improved configuration.The CodeQL initialization step has been updated to:
- Use the latest v3 GitHub CodeQL action
- Dynamically configure languages from the matrix
- Set build mode based on language requirements
These improvements align with GitHub's latest best practices for code scanning.
89-91: Optimized autobuild step with conditional execution.The autobuild step now only runs for Go language analysis, preventing unnecessary builds for languages that don't require it. This improves workflow efficiency.
92-95: Updated analyze step with improved categorization.The analyze step now uses:
- The latest v3 GitHub CodeQL action
- Proper categorization of results by language
This improvement helps organize security findings by language for better triage.
go.mod (10)
3-3: Updated Go version to 1.24.2.The Go version has been updated from 1.24.0 to 1.24.2, which includes security fixes and bug fixes from the Go team.
6-18: Updated Google Cloud dependencies.Google Cloud dependencies have been updated to their latest versions, which include:
cloud.google.com/gofrom v0.118.2 to v0.120.0- Storage, BigQuery, Monitoring, IAM, and other GCP services
These updates include bug fixes, performance improvements, and security patches.
25-28: Updated Azure SDK dependencies.Azure SDK components have been updated to newer versions, improving stability and security.
37-39: Updated common utility libraries.Important utility libraries have been updated:
- toml parser (BurntSushi/toml) to v1.5.0
- CloudSQL proxy to v1.37.6
These updates include bug fixes and security improvements.
48-68: Comprehensive AWS SDK update.The AWS SDK for Go v2 and all its components have been updated to more recent versions, including:
- Core SDK to v1.36.3
- S3, SQS, KMS, and other service clients
- Configuration and credential handlers
These updates include important bug fixes and security patches for AWS services.
195-196: Updated compression libraries.The Klauspost compression library has been updated to include the latest performance improvements and bug fixes. This is particularly important for the Vald project which relies on efficient data compression.
228-229: Updated testing framework dependencies.Testing dependencies have been updated:
- Ginkgo v2 to v2.23.3
- Gomega to v1.36.3
These updates improve testing stability and feature support.
240-243: Updated Prometheus monitoring stack.The Prometheus client and related libraries have been updated to their latest versions:
- client_golang to v1.21.1
- common to v0.63.0
- procfs to v0.16.0
These updates improve monitoring capabilities and fix known issues.
277-288: Updated OpenTelemetry dependencies.OpenTelemetry libraries have been updated to the latest v1.35.0, ensuring compatibility with the latest observability standards and protocols.
332-341: Updated Kubernetes client libraries.Kubernetes client libraries have been updated to v0.32.3, which includes important API compatibility updates and security fixes.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release/v1.7 #2908 +/- ##
===============================================
Coverage ? 17.78%
===============================================
Files ? 124
Lines ? 14216
Branches ? 0
===============================================
Hits ? 2529
Misses ? 11395
Partials ? 292 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
[FORMAT] Failed to format. |
…2e/add-e2e-test-v2-strategic-testing
vankichi
deleted the
backport/release/v1.7/feature/test-e2e/add-e2e-test-v2-strategic-testing
branch
3 participants
Overview
This PR introduces a new V2 E2E strategic testing framework for Vald, with significant refactoring and improvements to the testing infrastructure.
Key Changes
New V2 E2E Testing Framework:
tests/v2/e2e/Internal Package Refactoring:
internal/iterpackage for iterator abstractionsinternal/errorsinternal/paramsfor better argument parsinginternal/sync/errgroupfor improved concurrency handlingConfiguration Changes:
internal/config/config.goin theBind()methodconfigpackage for E2E testingCI/Workflow Improvements:
This pull request includes several updates across various files and configurations, primarily focusing on adding new test files, updating version numbers, and enhancing CI/CD workflows.
About the CI Warning
The CI system flagged changes in
internal/configthat might require Helm chart updates. After reviewing the changes, they appear to be relatively minor and focused on refactoring theBind()method rather than changing the structure of configuration itself. No Helm chart changes were included in this PR.Recommendations
Overall, this PR significantly improves the testing infrastructure and should enhance the maintainability of the codebase.
Related Issue
Versions
Checklist
Special notes for your reviewer
Summary by CodeRabbit
New Features
Enhancements
Testing & Maintenance