add metadata to megavault operator params #2509
Conversation
WalkthroughThe changes in this pull request focus on enhancing the TypeScript and protocol buffer definitions related to vault parameters. New interfaces and message types, Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (2)
protocol/x/vault/types/params.go (1)
90-90: Fix typo in the description.There's a typo in the
Descriptionfield. "Acccount" should be "Account".Apply this change:
- Description: "Governance Module Acccount", + Description: "Governance Module Account",protocol/scripts/genesis/sample_pregenesis.json (1)
3975-3979: Consider standardizing metadata across other modules.While the addition of metadata to the operator params in the vault section is beneficial, it might be worth considering if similar metadata could be added to other critical addresses or accounts throughout the configuration.
To maintain consistency and improve overall documentation:
- Review other modules in the configuration that have similar operator or account fields.
- Consider adding metadata fields to those modules as well, following the same structure (name and description).
- Ensure that the metadata is accurate and provides valuable context for each operator or account.
This standardization would further enhance the readability and maintainability of the configuration file.
🛑 Comments failed to post (3)
protocol/x/vault/types/params.go (1)
88-91: 🛠️ Refactor suggestion
Consider updating the Validate function for OperatorParams.
The
Validatefunction forOperatorParamsdoesn't include validation for the newMetadatafield. Consider adding validation to ensure theNameandDescriptionfields are not empty.Here's a suggested update to the
Validatefunction:func (o OperatorParams) Validate() error { // Validate that operator is non-empty. if o.Operator == "" { return ErrEmptyOperator } // Validate metadata if o.Metadata.Name == "" { return errors.New("metadata name cannot be empty") } if o.Metadata.Description == "" { return errors.New("metadata description cannot be empty") } return nil }proto/dydxprotocol/vault/params.proto (1)
68-68: 💡 Codebase verification
Deprecated
Paramsmessage is still in useThe shell script identified multiple usages of the deprecated
Paramsmessage across the codebase. To complete the deprecation process, please replace all instances ofParamswithQuotingParams.Examples of remaining usages:
protocol/testutil/keeper/perpetuals.goindexer/packages/v4-protos/src/codegen/helpers.tsprotocol/x/vault/keeper/deprecated_state.goprotocol/x/vault/types/params.pb.goprotocol/x/stats/types/params.goEnsure that these and any other occurrences are updated accordingly to fully remove the deprecated
Paramsmessage.🔗 Analysis chain
Verify usage of deprecated
ParamsmessageThe
Paramsmessage has been marked as deprecated and replaced byQuotingParams. This is a good step towards refactoring the module's parameter structure. However, it's crucial to ensure that all parts of the codebase using theParamsmessage are updated accordingly.To ensure a smooth transition, please run the following script to check for any remaining usages of the deprecated
Paramsmessage:Please review the results and update any remaining usages to use
QuotingParamsinstead.
Update Shell Script to Correct Type Identifier for TypeScript Files
The previous script encountered an error due to an unrecognized
typescriptfile type. I've corrected the file type identifier totsto properly target TypeScript files. Please run the updated script below to verify usages of the deprecatedParamsmessage:🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for usages of the deprecated Params message # Search for imports of the deprecated Params message echo "Checking for imports of deprecated Params message:" rg --type go --type rust --type typescript "import.*Params.*from.*vault/params" -g '!*_test*' # Search for usages of the Params type echo "Checking for usages of deprecated Params type:" rg --type go --type rust --type typescript "\bParams\b" -g '!*_test*' -g '!*params.proto'Length of output: 471
Script:
#!/bin/bash # Description: Check for usages of the deprecated Params message # Search for imports of the deprecated Params message echo "Checking for imports of deprecated Params message:" rg --type go --type rust --type ts "import.*Params.*from.*vault/params" -g '!*_test*' # Search for usages of the Params type echo "Checking for usages of deprecated Params type:" rg --type go --type rust --type ts "\bParams\b" -g '!*_test*' -g '!*params.proto'Length of output: 91362
indexer/packages/v4-protos/src/codegen/dydxprotocol/vault/params.ts (1)
97-101: 💡 Codebase verification
Inconsistent handling of
metadatafield inOperatorParamsusagesThe following files use the updated
OperatorParamsinterface but do not handle the newmetadatafield appropriately:
indexer/packages/v4-protos/src/codegen/dydxprotocol/vault/tx.rpc.msg.tsindexer/packages/v4-protos/src/codegen/dydxprotocol/vault/query.tsindexer/packages/v4-protos/src/codegen/dydxprotocol/vault/genesis.tsindexer/packages/v4-protos/src/codegen/dydxprotocol/vault/tx.tsPlease update these files to ensure that the
metadatafield is properly managed to prevent potential issues in data handling or serialization.🔗 Analysis chain
Ensure consistent usage of the updated
OperatorParamsinterfaceWith the addition of the optional
metadatafield to theOperatorParamsinterface, please verify that all usages ofOperatorParamsthroughout the codebase handle this new field appropriately, to prevent potential issues in data handling or serialization.Run the following script to find occurrences of
OperatorParamsand check for handling of themetadatafield:🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for usages of OperatorParams and check for metadata field handling. # Find all TypeScript files that reference OperatorParams rg --type ts 'OperatorParams' --files-with-matches | xargs rg 'metadata' # If `metadata` is not handled in certain usages, they will not appear in the resultsLength of output: 1262
Script:
#!/bin/bash # Description: Verify that all usages of OperatorParams handle the metadata field appropriately. # Find all TypeScript files that reference OperatorParams FILES=$(rg --type ts 'OperatorParams' --files-with-matches) # Initialize a variable to track files missing metadata handling ISSUE_FILES=() # Iterate through each file and check if 'metadata' is handled for file in $FILES; do if ! rg -q 'metadata\s*:' "$file"; then ISSUE_FILES+=("$file") fi done # Output files that do not handle metadata if [ ${#ISSUE_FILES[@]} -ne 0 ]; then echo "Files where OperatorParams is used but metadata is not handled:" for issue_file in "${ISSUE_FILES[@]}"; do echo "$issue_file" done else echo "All OperatorParams usages handle the metadata field appropriately." fiLength of output: 1965
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
protocol/x/vault/types/params.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (8)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/vault/params.ts (5 hunks)
- proto/dydxprotocol/vault/params.proto (1 hunks)
- protocol/app/testdata/default_genesis_state.json (1 hunks)
- protocol/scripts/genesis/sample_pregenesis.json (1 hunks)
- protocol/testing/genesis.sh (1 hunks)
- protocol/testutil/constants/genesis.go (1 hunks)
- protocol/x/vault/keeper/grpc_query_test.go (1 hunks)
- protocol/x/vault/types/params.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- proto/dydxprotocol/vault/params.proto
- protocol/app/testdata/default_genesis_state.json
- protocol/testutil/constants/genesis.go
- protocol/x/vault/types/params.go
🧰 Additional context used
🔇 Additional comments (7)
protocol/x/vault/keeper/grpc_query_test.go (1)
30-30: LGTM! Consider verifying other test files.The addition of the
Metadatafield to theOperatorParamsstructure in this test case is correct and aligns with the PR objectives. It ensures that the test coverage includes the new metadata field for operator parameters.To ensure comprehensive test coverage, please verify if other test files need similar updates:
✅ Verification successful
Change Verified
The addition of the
Metadatafield to theOperatorParamsstructure ingrpc_query_test.gois correctly implemented. No other test files require updates, as they do not utilize theMetadatafield inOperatorParams.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for other test files that might need updating with the new Metadata field. # Test: Search for other test files containing OperatorParams rg --type go -g '*_test.go' 'OperatorParams' # Test: Search for other occurrences of DefaultOperatorParams rg --type go -g '*_test.go' 'DefaultOperatorParams'Length of output: 3636
protocol/scripts/genesis/sample_pregenesis.json (3)
3975-3978: Addition of metadata to operator_params looks good.The changes introduce a
metadataobject within theoperator_paramsof thevaultmodule. This addition provides more context about the operator, which is beneficial for clarity and documentation purposes.The new fields are:
name: "Governance"description: "Governance Module Account"These metadata fields offer clear identification of the operator's role and purpose within the system.
Line range hint
1-3978: Overall, the changes look good and have minimal impact.The modifications to this file are limited to the
vaultsection, specifically theoperator_paramsobject. The addition of metadata improves the clarity of the configuration without altering any functional aspects.Key points:
- The changes are isolated to the
vaultmodule configuration.- No other parts of the file were modified.
- The added metadata provides useful context about the operator's role.
These changes enhance the documentation within the configuration file itself, which is a positive improvement for maintainability and understanding of the system's setup.
3975-3978: Verify consistency of metadata usage across the codebase.While the addition of metadata is beneficial, it's important to ensure that this change is reflected consistently across the entire codebase and documentation.
Please run the following script to check for any other occurrences of
operator_paramsand verify if they also include the new metadata fields:indexer/packages/v4-protos/src/codegen/dydxprotocol/vault/params.ts (2)
418-421: Consistent Handling in 'fromPartial' MethodThe
fromPartial()method forOperatorParamscorrectly checks ifmetadatais notundefinedornullbefore processing it. This ensures that partial updates toOperatorParamshandle the optionalmetadatafield appropriately.
424-473: Verify Implementation of 'OperatorMetadata' FunctionsThe
createBaseOperatorMetadata(),encode(),decode(), andfromPartial()functions forOperatorMetadataare correctly implemented. They follow the patterns established in the codebase for message types.protocol/testing/genesis.sh (1)
2276-2277: Verify handling of newmetadatafields inoperator_paramsThe addition of
metadata.nameandmetadata.descriptiontooperator_paramsin the genesis file aligns with the goal of enriching operator parameters with metadata. Ensure that all parts of the codebase that read or processoperator_paramsare updated to handle the newmetadatafields to prevent any potential issues during genesis initialization or runtime.Run the following script to verify that the codebase properly handles
operator_params.metadata:
| /** Address of the operator. */ | ||
| operator: string; | ||
| /** Metadata of the operator. */ | ||
|
|
||
| metadata?: OperatorMetadata; |
There was a problem hiding this comment.
Ensure Consistent Initialization of Optional Fields
The metadata field in OperatorParams and OperatorParamsSDKType is declared as optional. In the createBaseOperatorParams() function, it is initialized to undefined. To maintain consistency and avoid potential runtime errors when accessing metadata, consider initializing it with a default value.
Apply this diff to initialize metadata with a default OperatorMetadata object:
function createBaseOperatorParams(): OperatorParams {
return {
operator: "",
- metadata: undefined
+ metadata: createBaseOperatorMetadata()
};
}This change ensures that metadata is always an object, simplifying usage throughout the codebase.
Also applies to: 106-110
| case 2: | ||
| message.metadata = OperatorMetadata.decode(reader, reader.uint32()); | ||
| break; | ||
|
|
There was a problem hiding this comment.
Handle Optional 'metadata' Field in Decoding Logic
In the decode() method for OperatorParams, the decoding of metadata does not account for its optional nature. Ensure that the decoder handles the absence of the metadata field gracefully to prevent runtime exceptions.
Consider checking if the next tag corresponds to metadata before decoding, or handle the possibility that metadata might not be present in the input.
| operator: "", | ||
| metadata: undefined |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Initialize 'metadata' with a Default Value
In the createBaseOperatorParams() function, metadata is set to undefined. To prevent possible undefined errors when accessing metadata properties, initialize it using the createBaseOperatorMetadata() function.
Apply this diff:
function createBaseOperatorParams(): OperatorParams {
return {
operator: "",
- metadata: undefined
+ metadata: createBaseOperatorMetadata()
};
}This ensures that metadata has default values and aligns with the initialization pattern used elsewhere.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| operator: "", | |
| metadata: undefined | |
| operator: "", | |
| metadata: createBaseOperatorMetadata() |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
proto/dydxprotocol/vault/params.proto (2)
54-58: LGTM! Consider adding a comment for theoperatorfield.The
OperatorParamsmessage is well-structured and appropriate for storing operator-related information. The use ofcosmos_proto.scalarfor theoperatorfield is correct for Cosmos addresses.Consider adding a comment to clarify that the
operatorfield is expected to be a Cosmos address string. This can help prevent potential misuse:// Address of the operator. +// Expected to be a valid Cosmos address string. string operator = 1 [ (cosmos_proto.scalar) = "cosmos.AddressString" ];
61-65: LGTM! Consider adding field constraints.The
OperatorMetadatamessage is well-structured for storing basic operator information.Consider adding length constraints to the
nameanddescriptionfields to prevent excessively large metadata entries. This can be done using the[(gogoproto.moretags) = "validate:\"max=X\""]option, where X is the maximum allowed length. For example:// Name of the operator. -string name = 1; +string name = 1 [(gogoproto.moretags) = "validate:\"max=100\""]; // Adjust the max length as needed // Description of the operator. -string description = 2; +string description = 2 [(gogoproto.moretags) = "validate:\"max=500\""]; // Adjust the max length as neededThis change would require adding the
validateimport and using a validation library in your Go code, but it would help ensure that the metadata remains within reasonable size limits.protocol/x/vault/keeper/params_test.go (1)
392-392: LGTM! Consider adding a test for metadata validation.The changes correctly implement and test the new
Metadatafield in theOperatorParamsstructure. The test case is appropriately updated to include and verify the new metadata fields.Consider adding a test case to verify that invalid metadata (e.g., empty name or description) is properly handled or rejected.
Also applies to: 400-403
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
protocol/x/vault/types/params.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (9)
- indexer/packages/v4-protos/src/codegen/dydxprotocol/vault/params.ts (5 hunks)
- proto/dydxprotocol/vault/params.proto (1 hunks)
- protocol/app/testdata/default_genesis_state.json (1 hunks)
- protocol/scripts/genesis/sample_pregenesis.json (1 hunks)
- protocol/testing/genesis.sh (1 hunks)
- protocol/testutil/constants/genesis.go (1 hunks)
- protocol/x/vault/keeper/grpc_query_test.go (1 hunks)
- protocol/x/vault/keeper/params_test.go (1 hunks)
- protocol/x/vault/types/params.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- protocol/app/testdata/default_genesis_state.json
- protocol/testutil/constants/genesis.go
- protocol/x/vault/keeper/grpc_query_test.go
- protocol/x/vault/types/params.go
🧰 Additional context used
🔇 Additional comments (14)
proto/dydxprotocol/vault/params.proto (2)
Line range hint
1-105: Overall, the changes align well with the PR objectives.The additions of
OperatorParamsandOperatorMetadatamessages successfully introduce the ability to store metadata for megavault operators. The deprecation of theParamsmessage in favor ofQuotingParamsis also clearly indicated.A few minor suggestions have been made to improve field documentation and add constraints. Additionally, a verification step has been suggested to ensure that the deprecated
Paramsmessage is no longer in use across the codebase.These changes enhance the protocol's ability to manage operator-related data within the vault parameters, which aligns with the stated PR objective of adding metadata to megavault operator params.
68-68: Verify usage of deprecatedParamsmessage across the codebase.The
Paramsmessage is correctly marked as deprecated. However, it's important to ensure that all parts of the codebase are updated to use the newQuotingParamsinstead.To identify any remaining usage of the deprecated
Paramsmessage, run the following script:If any results are found, consider creating follow-up tasks to update those occurrences to use
QuotingParamsinstead.protocol/scripts/genesis/sample_pregenesis.json (4)
3975-3978: Addition of metadata to operator_params looks good.The changes introduce a
metadataobject to theoperator_paramsin thevaultsection. This addition provides more context about the operator, which is beneficial for clarity and documentation purposes.The metadata includes:
- A
namefield set to "Governance"- A
descriptionfield set to "Governance Module Account"These changes align well with the PR title "add metadata to megavault operator params" and improve the overall clarity of the configuration.
3975-3978: Summary of review for metadata addition to operator_params.The changes to add metadata to the
operator_paramsin thevaultsection of the genesis configuration file are straightforward and improve the clarity of the configuration. Here's a summary of the review:
- The addition of
nameanddescriptionfields to themetadataobject is approved and aligns with the PR objective.- We've recommended verifying consistency with other parts of the configuration to ensure this change is reflected appropriately throughout the system.
- While no direct security implications were identified, we've suggested considering potential indirect effects on access control, permissions, and file parsing.
Overall, this change appears to be a positive improvement to the configuration's documentation and clarity. Please address the verification points raised in the previous comments to ensure a smooth integration of this change.
3975-3978: Consider potential security implications.While the addition of metadata appears to be purely informational and doesn't introduce any direct security risks, it's worth considering a few points:
- Ensure that the added metadata doesn't inadvertently expose any sensitive information about the Governance Module Account.
- Verify that the addition of this metadata doesn't affect any access control or permission systems that might rely on the structure of the
operator_paramsobject.- Consider whether this change might impact any parsing or processing of the configuration file in other parts of the system.
To help verify these points, you could run the following script:
#!/bin/bash # Search for uses of operator_params in the codebase echo "Searching for uses of operator_params:" rg "operator_params" --type go echo "\nSearching for parsing of the genesis file:" rg "sample_pregenesis.json" --type goThis will help identify any code that might be affected by the structure change in
operator_params.
3975-3978: Verify consistency with other configuration sections.While the addition of metadata to the
operator_paramsis a good improvement, it's important to ensure consistency across the configuration. Please verify:
- Are there other sections in the configuration that might benefit from similar metadata additions?
- Is the "Governance" name and description consistent with how this entity is referred to in other parts of the configuration or documentation?
- Are there any other places in the configuration that reference the operator and might need updating to reflect this additional information?
To help with this verification, you can run the following script:
This will help identify other areas of the configuration that might need to be reviewed for consistency.
✅ Verification successful
Consistency of metadata additions confirmed across configuration sections.
The additions of
"metadata"in bothsample_pregenesis.jsonanddefault_genesis_state.jsonare consistent. The"Governance"name and description are uniformly referenced across these configuration files, ensuring coherent configuration updates.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other occurrences of the operator address and governance references echo "Searching for operator address occurrences:" grep -n "dydx10d07y265gmmuvt4z0w9aw880jnsr700jnmapky" protocol/scripts/genesis/sample_pregenesis.json echo "\nSearching for 'Governance' references:" grep -n -i "governance" protocol/scripts/genesis/sample_pregenesis.jsonLength of output: 1011
Script:
#!/bin/bash # Correctly search JSON configuration files for metadata additions and 'Governance' references echo "Searching for metadata additions in JSON configuration files:" rg '"metadata"' --type json echo "\nSearching for 'Governance' references across all JSON configuration files:" rg -i "governance" --type jsonLength of output: 861
indexer/packages/v4-protos/src/codegen/dydxprotocol/vault/params.ts (8)
97-101: Initialization of 'metadata' Should Use Default ValuesThe
metadatafield inOperatorParamsis initialized toundefinedin thecreateBaseOperatorParams()function. To avoid potential runtime errors when accessingmetadata, initialize it with a defaultOperatorMetadataobject.
106-110: Consistent Initialization of Optional FieldsSimilar to the previous comment, in the
OperatorParamsSDKType, themetadatafield is initialized toundefined. It's recommended to initializemetadatawith a default value to maintain consistency and prevent potential undefined errors.
114-122: 'OperatorMetadata' Interface is Well-DefinedThe introduction of the
OperatorMetadatainterface enhances the structure by providing clear fields fornameanddescription. The definitions are clear and follow TypeScript conventions.
371-372: Initialize 'metadata' with a Default Value in 'createBaseOperatorParams()'In the
createBaseOperatorParams()function,metadatais set toundefined. To prevent possibleundefinederrors when accessingmetadataproperties, initialize it using thecreateBaseOperatorMetadata()function.
382-385: Proper Encoding of Optional 'metadata' FieldThe encoding logic for
metadatain theOperatorParams.encode()method correctly checks ifmetadatais defined before encoding. This ensures optional fields are handled appropriately.
402-405: Handle Optional 'metadata' Field in Decoding LogicIn the
OperatorParams.decode()method, the decoding ofmetadataassumes its presence. Ensure the decoder handles the absence of themetadatafield gracefully to prevent runtime exceptions.
418-421: Proper Handling of 'metadata' in 'fromPartial' MethodThe
fromPartial()method forOperatorParamscorrectly handles themetadatafield, ensuring that partial data is accommodated without issues.
424-473: 'OperatorMetadata' Encoding and Decoding Logic is CorrectThe implementation of encoding, decoding, and partial assignment for
OperatorMetadatais correct. The functions handle the fields appropriately, ensuring reliable serialization and deserialization.
| dasel put -t string -f "$GENESIS" ".app_state.vault.operator_params.metadata.name" -v 'Governance' | ||
| dasel put -t string -f "$GENESIS" ".app_state.vault.operator_params.metadata.description" -v 'Governance Module Account' |
There was a problem hiding this comment.
💡 Codebase verification
'metadata' field not found in 'OperatorParams'
The OperatorParams message does not include the metadata field as defined. Please ensure that the metadata field is properly defined within OperatorParams in the protocol buffer definitions. Without this field being defined, the genesis processing may fail.
- File:
protocol/testing/genesis.shlines 2276-2277 useoperator_params.metadata
🔗 Analysis chain
Verify the inclusion of 'metadata' fields in 'operator_params'.
The code adds metadata.name and metadata.description to operator_params. Ensure that these fields are supported in the operator_params structure and that all necessary consuming code correctly handles these new fields without causing issues during genesis processing.
Run the following script to check if metadata is a valid field in operator_params throughout the codebase:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that 'metadata' is a recognized field within 'operator_params'.
# Search for the definition of 'OperatorParams' and check for 'metadata' field.
ast-grep --lang proto --pattern $'message OperatorParams {
$$$
OperatorMetadata metadata = $_;
$$$
}'
# Search for usages of 'operator_params.metadata' in the codebase.
rg --type shell --type go '\operator_params\.metadata' -A 5 -B 5
Length of output: 379
Script:
#!/bin/bash
# Description: Verify that 'metadata' is a recognized field within 'OperatorParams'.
# Search for the definition of 'OperatorParams' and check for 'metadata' field in .proto files.
rg 'message OperatorParams\s*\{[^}]*OperatorMetadata\s+metadata\s+=' --type proto
# Search for usages of 'operator_params.metadata' in shell and Go files.
rg 'operator_params\.metadata' --type sh --type go -A 5 -B 5
Length of output: 1264
Script:
#!/bin/bash
# Description: Verify that 'metadata' is a recognized field within 'OperatorParams'.
# Define the 'proto' file type for rg
rg --type-add 'proto:*.proto' --type proto 'message OperatorParams\s*\{[^}]*OperatorMetadata\s+metadata\s+='
# Search for usages of 'operator_params.metadata' in shell and Go files with corrected regex
rg 'operator_params\\.metadata' --type sh --type go -A 5 -B 5
Length of output: 174
Changelist
[Describe or list the changes made in this PR]
Test Plan
[Describe how this PR was tested (if applicable)]
Author/Reviewer Checklist
state-breakinglabel.indexer-postgres-breakinglabel.PrepareProposalorProcessProposal, manually add the labelproposal-breaking.feature:[feature-name].backport/[branch-name].refactor,chore,bug.Summary by CodeRabbit
New Features
Bug Fixes
Paramsmessage, ensuring clarity in protocol usage.Documentation
Tests