-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/meta/save metadata #2624
Conversation
WalkthroughWalkthroughThe pull request introduces a new metadata management feature to the API, encompassing the addition of a Changes
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 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 (
|
13916e8
to
f2e604f
Compare
Deploying vald with Cloudflare Pages
|
f2e604f
to
f43c33a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
Outside diff range and nitpick comments (1)
rust/libs/proto/src/payload.v1.rs (1)
1241-1244
: LGTM, but consider adding a doc comment to clarify the purpose.The empty
Meta
struct has been introduced correctly. However, its purpose is unclear. Consider adding a documentation comment to explain its intended usage, even if it's a placeholder for now.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (8)
apis/grpc/v1/agent/sidecar/sidecar_vtproto.pb.go
is excluded by!**/*.pb.go
,!**/*.pb.go
apis/grpc/v1/meta/meta.pb.go
is excluded by!**/*.pb.go
,!**/*.pb.go
apis/grpc/v1/meta/meta_vtproto.pb.go
is excluded by!**/*.pb.go
,!**/*.pb.go
apis/grpc/v1/payload/payload.pb.go
is excluded by!**/*.pb.go
,!**/*.pb.go
apis/grpc/v1/payload/payload.pb.json.go
is excluded by!**/*.pb.json.go
apis/grpc/v1/payload/payload_vtproto.pb.go
is excluded by!**/*.pb.go
,!**/*.pb.go
apis/grpc/v1/rpc/errdetails/error_details.pb.go
is excluded by!**/*.pb.go
,!**/*.pb.go
rust/Cargo.lock
is excluded by!**/*.lock
Files selected for processing (13)
- apis/docs/v1/docs.md (4 hunks)
- apis/proto/v1/meta/meta.proto (1 hunks)
- apis/proto/v1/payload/payload.proto (2 hunks)
- apis/swagger/v1/meta/meta.swagger.json (1 hunks)
- rust/Cargo.toml (1 hunks)
- rust/bin/meta/Cargo.toml (1 hunks)
- rust/bin/meta/src/handler.rs (1 hunks)
- rust/bin/meta/src/handler/meta.rs (1 hunks)
- rust/bin/meta/src/main.rs (1 hunks)
- rust/libs/proto/Cargo.toml (1 hunks)
- rust/libs/proto/src/lib.rs (1 hunks)
- rust/libs/proto/src/meta.v1.tonic.rs (1 hunks)
- rust/libs/proto/src/payload.v1.rs (1 hunks)
Files skipped from review due to trivial changes (1)
- rust/bin/meta/src/handler.rs
Additional context used
buf
apis/proto/v1/meta/meta.proto
21-21: import "google/api/annotations.proto": file does not exist
(COMPILE)
checkov
apis/swagger/v1/meta/meta.swagger.json
[HIGH] 1-167: Ensure that security requirement defined in securityDefinitions - version 2.0 files
(CKV_OPENAPI_6)
[HIGH] 1-167: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[HIGH] 1-167: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[HIGH] 1-167: Ensure that securityDefinitions is defined and not empty - version 2.0 files
(CKV_OPENAPI_1)
Markdownlint
apis/docs/v1/docs.md
688-688: null
Link fragments should be valid(MD051, link-fragments)
Additional comments not posted (26)
rust/Cargo.toml (1)
20-20
: LGTM!The addition of the
"bin/meta"
member to the[workspace]
section is correct and consistent with the PR objective of introducing metadata functionality.rust/libs/proto/Cargo.toml (1)
26-26
: LGTM!The addition of the
prost-types
dependency with version0.13.2
is consistent with the existingprost
andtonic
dependencies. It aligns with the purpose of enhancing protocol buffer functionality in the project.rust/bin/meta/Cargo.toml (3)
1-15
: License header looks good.The file includes the standard Apache License 2.0 header with the appropriate copyright notice. The formatting and content of the license header are correct.
16-19
: Package configuration is appropriate.The package configuration specifies the correct name, version, and edition for the
meta
binary target. The package name aligns with the purpose of the binary, the version indicates an initial release, and the edition is set to the latest stable version of Rust.
21-24
: Dependencies are properly specified.The dependencies required by the
meta
binary target are appropriately listed:
- The
proto
dependency is sourced from a local path, suggesting a custom library within the project.- The
tokio
dependency is included with the "full" feature set, enabling asynchronous runtime capabilities.- The
tonic
dependency is specified with a specific version, ensuring compatibility with the gRPC framework.The dependencies are relevant and necessary for the functionality of the
meta
binary target.rust/libs/proto/src/lib.rs (1)
40-44
: LGTM!The addition of the
meta
module and its submodulev1
follows the existing pattern in the library and is consistent with the library's structure and naming conventions. The inclusion of themeta.v1.tonic.rs
file suggests that themeta
module will contain metadata-related functionality, likely generated using the Tonic framework for gRPC.The changes enhance the library's structure by organizing related functionalities under the new
meta
namespace, which may facilitate better code management and modularization.rust/bin/meta/src/main.rs (1)
1-30
: LGTM!The code in
main.rs
looks good overall:
- It follows Rust conventions and best practices.
- It uses
tokio
for async execution and returns aResult
frommain
for error handling.- It sets up a gRPC server using
tonic
, which is a good choice.- It creates an instance of the
Meta
handler using itsdefault
method, registers it as a service, and starts the server correctly.No issues found. Good job!
rust/bin/meta/src/handler/meta.rs (3)
21-26
: LGTM! Remember to implement the method.The method signature is correct and matches the gRPC service definition. Please remember to implement the method before merging this PR.
27-32
: LGTM! Remember to implement the method.The method signature is correct and matches the gRPC service definition. Please remember to implement the method before merging this PR.
34-39
: LGTM! Remember to implement the method.The method signature is correct and matches the gRPC service definition. Please remember to implement the method before merging this PR.
apis/proto/v1/meta/meta.proto (2)
30-45
: LGTM!The
Meta
service and its methods (Get
,Set
, andDelete
) are correctly defined using the Protocol Buffers syntax. The service definition follows the standard conventions and includes the appropriate HTTP annotations for each method.
22-22
: Verify the relative import path forv1/payload/payload.proto
.The import statement assumes a relative path for
v1/payload/payload.proto
. Please ensure that this file exists at the specified location relative to the current file.Run the following script to verify the import path:
Verification successful
Import path is correct. The file
apis/proto/v1/payload/payload.proto
exists at the specified location, confirming that the import path inapis/proto/v1/meta/meta.proto
is correct.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence of the imported file. # Test: Check if the file exists relative to the current file. if [ -f "apis/proto/v1/payload/payload.proto" ]; then echo "Import path is correct. File exists at apis/proto/v1/payload/payload.proto" else echo "Import path is incorrect. File does not exist at apis/proto/v1/payload/payload.proto" fiLength of output: 207
apis/swagger/v1/meta/meta.swagger.json (3)
1-13
: LGTM!The API info and tags are properly defined.
Tools
checkov
[HIGH] 1-167: Ensure that security requirement defined in securityDefinitions - version 2.0 files
(CKV_OPENAPI_6)
[HIGH] 1-167: Ensure that the global security field has rules defined
(CKV_OPENAPI_4)
[HIGH] 1-167: Ensure that security operations is not empty.
(CKV_OPENAPI_5)
[HIGH] 1-167: Ensure that securityDefinitions is defined and not empty - version 2.0 files
(CKV_OPENAPI_1)
14-99
: LGTM!The API paths and operations are well-structured and consistent. The request/response schemas are properly referenced.
100-165
: LGTM!The API models are accurately defined with proper types, references and detailed descriptions.
rust/libs/proto/src/meta.v1.tonic.rs (3)
16-171
: LGTM!The
meta_client
module provides a well-structured and idiomatic Rust implementation of a gRPC client for theMeta
service. The code follows best practices and effectively utilizes thetonic
library for gRPC functionality.
173-456
: LGTM!The
meta_server
module provides a well-structured and idiomatic Rust implementation of a gRPC server for theMeta
service. The code follows best practices, such as defining a trait for the server methods, implementing necessary traits from thetonic
library, and handling incoming requests effectively usingasync
/await
.
1-456
: Excellent work!The
rust/libs/proto/src/meta.v1.tonic.rs
file provides a well-structured, idiomatic, and efficient implementation of a gRPC client and server for theMeta
service using thetonic
library. The code follows Rust best practices and effectively utilizesasync
/await
for asynchronous programming. Great job!apis/proto/v1/payload/payload.proto (1)
780-793
: LGTM! The newMeta
message structure enhances flexibility and extensibility.The introduction of the
Meta
message structure, along with its nestedKey
,Value
, andKeyValue
messages, provides a powerful mechanism for storing and associating diverse data types with specific keys. This addition expands the capabilities of the payload without affecting existing functionality.Key highlights:
- The
Key
message allows for clear identification of each metadata entry.- The
Value
message, utilizing thegoogle.protobuf.Any
type, enables the storage of any arbitrary message type, promoting extensibility.- The
KeyValue
message establishes a strong relationship between a key and its corresponding value, ensuring clarity and ease of use.These enhancements offer great flexibility and adaptability for future metadata requirements.
rust/libs/proto/src/payload.v1.rs (3)
1247-1252
: Looks good!The
Key
struct with thekey
field of typeString
has been defined correctly.
1253-1258
: Looks good!The
Value
struct with the optionalvalue
field of typeAny
has been defined correctly. UsingAny
allows flexibility in the types of values that can be stored.
1259-1266
: Looks good!The
KeyValue
struct correctly composes theKey
andValue
structs to represent a key-value pair. Making both fields optional allows for flexibility in usage.apis/docs/v1/docs.md (4)
53-56
: LGTM!The addition of the
Meta
entry to the table of contents is consistent with the introduction of the newMeta
section in the documentation.
661-689
: Documentation for the newMeta
message type looks good!The
Meta
message type and its fields (Meta.Key
,Meta.KeyValue
, andMeta.Value
) are clearly documented, following the existing documentation structure.Note that the
Meta.Value
field uses thegoogle.protobuf.Any
type, which allows for storing arbitrary message types. While this provides flexibility, it may require additional handling in the code to pack and unpack the stored value.Tools
Markdownlint
688-688: null
Link fragments should be valid(MD051, link-fragments)
1346-1361
: LGTM!The documentation for the new
Meta
service and its methods (Get
,Set
, andDelete
) is clear, concise, and consistent with the existing documentation structure.
688-688
: The static analysis hint about the link fragment is a false positive and can be safely ignored, as the link fragment is valid and points to the correct location in the documentation.Tools
Markdownlint
688-688: null
Link fragments should be valid(MD051, link-fragments)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Description
Related Issue
Versions
Checklist
Special notes for your reviewer
Summary by CodeRabbit
New Features
Get
,Set
, andDelete
methods for handling key-value pairs.Bug Fixes
Documentation
Chores