refactor(schema)!: rename ObjectType -> StateObjectType #21691
Conversation
WalkthroughWalkthroughThe changes involve a comprehensive refactoring of the codebase to transition from using general object types ( Changes
Possibly related PRs
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
Documentation and Community
|
aaronc
requested review from
testinginprod,
a team and
cool-develope
as code owners
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (1)
schema/state_object_test.go (1)
Line range hint
136-150: Approved with a suggestion.Using
StateObjectTypein this test case is consistent with the new type definition. Testing the behavior when an object type has a duplicate key field name is important for maintaining data integrity.However, the test case name "duplicate field 22" seems arbitrary. Consider renaming it to something more descriptive like "duplicate key field name" to enhance the readability and maintainability of the test suite.
Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (32)
- indexer/postgres/create_table_test.go (1 hunks)
- indexer/postgres/internal/testdata/example_schema.go (3 hunks)
- indexer/postgres/module.go (1 hunks)
- indexer/postgres/object.go (1 hunks)
- indexer/postgres/select.go (5 hunks)
- indexer/postgres/view.go (1 hunks)
- schema/appdata/data.go (1 hunks)
- schema/decoder.go (1 hunks)
- schema/decoding/decoding_test.go (11 hunks)
- schema/decoding/resolver_test.go (3 hunks)
- schema/diff/diff.go (4 hunks)
- schema/diff/diff_test.go (12 hunks)
- schema/diff/state_object_diff.go (3 hunks)
- schema/diff/state_object_diff_test.go (4 hunks)
- schema/fields.go (1 hunks)
- schema/module_schema.go (5 hunks)
- schema/module_schema_test.go (14 hunks)
- schema/state_object.go (3 hunks)
- schema/state_object_test.go (18 hunks)
- schema/state_object_update.go (2 hunks)
- schema/testing/appdatasim/app_data.go (1 hunks)
- schema/testing/example_schema.go (8 hunks)
- schema/testing/fmt.go (1 hunks)
- schema/testing/fmt_test.go (2 hunks)
- schema/testing/module_schema.go (1 hunks)
- schema/testing/object.go (5 hunks)
- schema/testing/object_test.go (1 hunks)
- schema/testing/statesim/app.go (1 hunks)
- schema/testing/statesim/module.go (4 hunks)
- schema/testing/statesim/object_coll.go (3 hunks)
- schema/type.go (4 hunks)
- schema/view/object.go (1 hunks)
Files skipped from review due to trivial changes (2)
- schema/fields.go
- schema/state_object_update.go
Additional context used
Path-based instructions (30)
schema/testing/object_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/testing/module_schema.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.indexer/postgres/object.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/testing/fmt.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/view/object.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/testing/fmt_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"indexer/postgres/module.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/decoder.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.indexer/postgres/internal/testdata/example_schema.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/type.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.indexer/postgres/create_table_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"indexer/postgres/view.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/testing/statesim/module.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/decoding/resolver_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/testing/object.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/testing/statesim/app.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/testing/example_schema.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/state_object.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/diff/state_object_diff.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/testing/statesim/object_coll.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/diff/diff.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/appdata/data.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/module_schema.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/state_object_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/testing/appdatasim/app_data.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.indexer/postgres/select.go (1)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.schema/module_schema_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/diff/state_object_diff_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/diff/diff_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"schema/decoding/decoding_test.go (2)
Pattern
**/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.
Pattern
**/*_test.go: "Assess the unit test code assessing sufficient code coverage for the changes associated in the pull request"
Additional comments not posted (147)
schema/testing/object_test.go (2)
12-12: LGTM!The change to use
StateObjectTypeGenaligns with the overall refactoring and the test still validates the generated object type correctly.
19-21: LGTM!The changes to use
StateObjectTypeGenandStateObjectInsertGenalign with the overall refactoring. The test still generates and validates the object type and update correctly, maintaining sufficient coverage.schema/testing/module_schema.go (1)
19-19: LGTM! Verify ModuleSchemaGen's behavior with unit tests.The change from
ObjectTypeGentoStateObjectTypeGenaligns with the broader refactoring toStateObjectType. It's a valid modification within theModuleSchemaGenfunction.However, as this function generates test schemas, it's crucial to verify that its behavior remains as expected with this change. Please ensure there are sufficient unit tests covering the various scenarios handled by
ModuleSchemaGento catch any potential issues introduced by usingStateObjectTypeGen.indexer/postgres/object.go (2)
12-12: LGTM!The change from
schema.ObjectTypetoschema.StateObjectTypefor thetypfield in theobjectIndexerstruct is consistent with the PR objective and the AI-generated summary. It improves clarity by using a more specific type name.
19-19: LGTM!Updating the constructor function
newObjectIndexerto acceptschema.StateObjectTypeinstead ofschema.ObjectTypeis necessary to match the updated type of thetypfield in theobjectIndexerstruct. This change is consistent with the PR objective and the AI-generated summary.schema/testing/fmt.go (1)
14-14: LGTM! The change is a breaking change but is necessary and consistent with the PR objective.I can confirm that:
- The change in the function signature from
schema.ObjectTypetoschema.StateObjectTypeis consistent with the PR objective of renamingObjectTypetoStateObjectTypeto reduce confusion and improve clarity.- The change is a breaking change, as it affects the public API of the function.
- The change is necessary to ensure that the function works with the new
StateObjectTypetype.- The function logic remains unchanged, and the change is limited to the parameter type.
- The change does not introduce any new issues or bugs.
schema/view/object.go (4)
6-9: LGTM!The comment provides clear guidelines on the usage of
StateObjectUpdateand handling ofValueUpdates. It helps in understanding the expected behavior.
13-13: Looks good!The change in the return type of
ObjectTypemethod toschema.StateObjectTypealigns with the overall renaming effort to provide more specific types related to state management.
18-18: Looks good!The change in the return type of
GetObjectmethod toschema.StateObjectUpdateis consistent with the renaming effort to provide more specific types related to state management.
23-23: Looks good!The change in the function parameter type of
AllStatemethod toschema.StateObjectUpdateis consistent with the renaming effort to provide more specific types related to state management.schema/testing/fmt_test.go (5)
11-11: LGTM!The change from
schema.ObjectTypetoschema.StateObjectTypealigns with the PR objective and is consistent with the AI-generated summary. It does not introduce any issues in the test case.
Line range hint
16-22: Looks good!The
objectTypefield has been correctly updated to useschema.StateObjectType, consistent with the change at line 11. The test case structure remains intact.
26-30: Looks good!The
objectTypefield has been correctly updated to useschema.StateObjectType, consistent with the change at line 11. The test case structure remains intact.
Line range hint
34-43: Looks good!The
objectTypefield has been correctly updated to useschema.StateObjectType, consistent with the change at line 11. The test case structure remains intact.
Line range hint
9-64: Test coverage looks sufficient.The
TestObjectKeyStringfunction provides good test coverage for theObjectKeyStringfunction. It tests the function with different object types and key values, covering important scenarios and edge cases. The assertions ensure that the function produces the expected output for each test case.indexer/postgres/module.go (1)
Line range hint
43-51: LGTM!The change from
ObjectTypestoStateObjectTypesaligns with the PR objective of improving clarity by using a more specific type name. The table creation logic remains unchanged and error handling is still in place.The code segment adheres to the Uber Go Style Guide.
schema/decoder.go (2)
16-18: LGTM!The changes to the
KVDecoderfunction signature and associated comment accurately reflect the transition to state-specific object updates. The code segment follows the Uber Golang style guide.
27-27: LGTM!The change to the
KVDecodertype alias accurately reflects the transition to state-specific object updates. The code segment follows the Uber Golang style guide.indexer/postgres/internal/testdata/example_schema.go (4)
7-7: LGTM!The change from
schema.ObjectTypetoschema.StateObjectTypeforAllKindsObjectaligns with the PR objective of improving clarity by using more specific state-related types.
10-10: Looks good!The initialization of
AllKindsObjecthas been correctly updated to match the type change toschema.StateObjectType.
48-48: LGTM!The change from
schema.ObjectTypetoschema.StateObjectTypeforSingletonObjectaligns with the PR objective of improving clarity by using more specific state-related types.
68-68: Looks good!The change from
schema.ObjectTypetoschema.StateObjectTypeforVoteObjectaligns with the PR objective of improving clarity by using more specific state-related types.schema/type.go (6)
4-4: LGTM!The comment change is consistent with the PR objective and the code changes made in the rest of the file.
25-26: LGTM!The new
LookupStateObjectTypemethod is consistent with the existingLookupEnumTypemethod and aligns with the PR objective.
39-41: LGTM!The new
StateObjectTypesmethod is consistent with the existingEnumTypesmethod and aligns with the PR objective.
65-66: LGTM!The
LookupStateObjectTypemethod change is consistent with the changes made to theTypeSetinterface and aligns with the PR objective.
73-73: LGTM!The
StateObjectTypesmethod change is consistent with the changes made to theTypeSetinterface and aligns with the PR objective.
Line range hint
1-76: Conforms to the Uber Golang style guide.The file follows the Uber Golang style guide, using the correct naming conventions, formatting, and indentation.
indexer/postgres/create_table_test.go (2)
82-84: LGTM!The function signature update is consistent with the PR objective. No other changes or additional tests are required for this function.
Line range hint
86-96: Looks good, but consider adding more test cases if needed.The function signature update is consistent with the PR objective. The existing example functions seem to cover the SQL generation logic sufficiently. However, consider adding more example functions if there are specific
StateObjectTypes that warrant additional test cases to maintain adequate coverage.indexer/postgres/view.go (3)
103-103: LGTM!The function change aligns with the PR objective of renaming
ObjectTypetoStateObjectTypeto improve clarity. The implementation is correct.
107-107: Verify the implementation oftm.get.The function change aligns with the PR objective of using more specific state-related types. The implementation looks good, assuming that
tm.gethas been updated to returnschema.StateObjectUpdate.Please ensure that the implementation of
tm.gethas been updated to returnschema.StateObjectUpdate.
111-111: Verify the implementation oftm.readRow.The function change aligns with the PR objective of using more specific state-related types. The implementation looks good, assuming that
tm.readRowhas been updated to returnschema.StateObjectUpdate.Please ensure that the implementation of
tm.readRowhas been updated to returnschema.StateObjectUpdate.schema/testing/statesim/module.go (6)
19-19: LGTM!The change in the type of
updateGenfield from*rapid.Generator[schema.ObjectUpdate]to*rapid.Generator[schema.StateObjectUpdate]aligns with the PR objective of transitioning to more specific state-related types. This improves clarity and specificity in the module's state management.
27-27: Looks good!Updating the
NewModulefunction to usemoduleSchema.StateObjectTypesinstead ofmoduleSchema.ObjectTypesensures that the module is specifically working with state object types. This change enhances the module's alignment with state management and improves code clarity.
Line range hint
36-41: Approved!Modifying the generator for updates to generate
schema.StateObjectUpdateinstances instead ofschema.ObjectUpdateis a correct implementation that aligns with the transition to more specific state-related types. This change ensures consistency in handling state object updates throughout the module's functionality.
52-52: Change looks good!Updating the
ApplyUpdatemethod to acceptschema.StateObjectUpdateinstead ofschema.ObjectUpdatereflects the shift towards handling more specific state-related updates. This change ensures that the module consistently works with state object updates, improving code clarity and maintainability.
63-63: Approved!Updating the return type of the
UpdateGenmethod to*rapid.Generator[schema.StateObjectUpdate]ensures consistency with the transition to more specific state-related types. This change maintains coherence throughout the module and improves code clarity by accurately reflecting the type of updates being generated.
Line range hint
1-97: Conforms to the Uber Golang Style Guide.A thorough review of the code in this file confirms that it adheres to the guidelines and best practices outlined in the Uber Golang Style Guide. The naming conventions, formatting, and code structure are consistent with the recommendations provided in the guide. No deviations or style issues were identified.
schema/decoding/resolver_test.go (4)
13-13: LGTM!The change from
schema.ObjectTypetoschema.StateObjectTypealigns with the PR objective and maintains the existing schema structure. The code segment adheres to the Uber Golang style guide.
25-25: Looks good!The transition from
schema.ObjectTypetoschema.StateObjectTypeis consistent with the changes made inmodAand aligns with the PR objective. The code segment follows the Uber Golang style guide.
48-48: Looks good to me!The type assertion update from
schema.ObjectTypetoschema.StateObjectTypecorrectly reflects the changes made in theModuleCodecmethods. The test logic is preserved, and the code segment adheres to the Uber Golang style guide.
Line range hint
1-144: Unit test coverage looks sufficient.The unit tests in this file provide adequate coverage for the
ModuleSetDecoderResolverfunctionality, considering the changes made in the pull request. The tests verify the behavior of the code with the updatedStateObjectTypeand ensure that the essential functionality, such as iteration, decoder lookup, and error handling, works as expected. The test cases cover different scenarios and check for the presence of expected object types within the module schemas.Based on the provided tests, the code coverage appears to be sufficient for the changes associated with this pull request.
schema/testing/object.go (3)
Line range hint
10-44: LGTM!The renaming of
ObjectTypeGentoStateObjectTypeGenand the change in return type fromschema.ObjectTypetoschema.StateObjectTypealign well with the PR objective to transition to more specific state-related types. The internal logic remains sound, correctly filtering out duplicate field names. The function is well-structured and follows the Uber Go Style Guide.
58-60: Looks good!The renaming of
ObjectInsertGentoStateObjectInsertGenand the update of the parameter type fromschema.ObjectTypetoschema.StateObjectTypeare in line with the PR objective. The function correctly callsStateObjectUpdateGenwith the providedobjectTypeandtypeSet, andnilfor thestateparameter. The implementation follows the Uber Go Style Guide.
Line range hint
63-103: Excellent work!The renaming of
ObjectUpdateGentoStateObjectUpdateGenand the update of the parameter and return types to useschema.StateObjectTypeandschema.StateObjectUpdateare consistent with the PR objective. The internal logic has been correctly adapted to accommodate the new state-specific types, ensuring that the function generates valid updates and filters out keys that exist in the state. The implementation is well-structured and adheres to the Uber Go Style Guide.schema/testing/statesim/app.go (1)
45-45: LGTM! The type change aligns with the refactoring goal.The change from
schema.ObjectUpdatetoschema.StateObjectUpdatefor theupdatesslice is consistent with the overall refactoring goal of transitioning to more specific state-related types. This improves clarity and reduces confusion in the context of state management.Please ensure that the
schema.StateObjectUpdatetype is defined and used consistently across the codebase. You can use the following command to search for its usage:Verification successful
Verification Successful: Consistent Usage of
schema.StateObjectUpdateAcross the CodebaseThe
schema.StateObjectUpdatetype is consistently used across various files in the codebase, aligning with the refactoring goal of transitioning to more specific state-related types. This confirms the change improves clarity and reduces confusion in state management contexts. No issues were found.
- Files with usage include
schema/view/object.go,schema/testing/object.go,schema/testing/statesim/module.go,schema/testing/statesim/object_coll.go,schema/testing/statesim/app.go,schema/testing/appdatasim/app_data.go,schema/decoding/decoding_test.go,schema/appdata/data.go, andindexer/postgres/view.go.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of `schema.StateObjectUpdate` type across the codebase. # Test: Search for the type usage. Expect: Consistent usage across the codebase. rg --type go $'schema.StateObjectUpdate'Length of output: 4395
schema/testing/example_schema.go (8)
Line range hint
14-28: LGTM!The change from
schema.ObjectTypetoschema.StateObjectTypefor the "Singleton" object is consistent with the PR objective. The key and value fields seem appropriate.
Line range hint
28-47: Looks good!The transition to
schema.StateObjectTypefor the "Simple" object aligns with the PR's refactoring goal. The string key field and int32/bytes value fields are suitable.
Line range hint
47-60: Looks good to me!Changing to
schema.StateObjectTypefor "TwoKeys" matches the PR's intent. Using a string and int32 as key fields is valid, and omitting value fields is acceptable for objects only needing unique keys.
Line range hint
60-83: Looks good!Updating "ThreeKeys" to use
schema.StateObjectTypeis in line with the PR's refactoring goal. The combination of string, int32, and uint64 key fields, along with an int32 value field, illustrates the flexibility in defining object schemas.
Line range hint
83-110: LGTM!Refactoring "ManyValues" to
schema.StateObjectTypefollows the PR's goal. The string key field and diverse set of value fields (int32, bytes, float64, uint64) demonstrate the range of data an object can hold.
Line range hint
110-129: Looks good!Changing "RetainDeletions" to
schema.StateObjectTypealigns with the PR's refactoring aim. The string key and int32/bytes value fields are appropriate, and enablingRetainDeletionscould be beneficial for auditing or recovery scenarios.
Line range hint
144-169: LGTM!Updating
mkTestObjectTypeto returnschema.StateObjectTypeinstead ofschema.ObjectTypeis consistent with the PR's refactoring goal. The function's logic for generating object types based on the provided kind remains appropriately unchanged.
Line range hint
1-176: Overall assessment: LGTM!The changes in this file consistently refactor
schema.ObjectTypetoschema.StateObjectTypeacross various example object definitions and themkTestObjectTypefunction. The updates align with the PR's goal of renaming the type to better convey its state-related purpose. The example objects showcase a range of valid configurations, including different key and value field types, multiple keys, and theRetainDeletionsproperty. No issues or inconsistencies were found in the changes.schema/state_object.go (6)
5-6: LGTM!The renaming of
ObjectTypetoStateObjectTypeand the updated comment improve clarity and align with the PR objective.
33-33: LGTM!The
TypeNamemethod has been correctly updated to use the newStateObjectTypereceiver type.
37-37: LGTM!The
isTypemethod has been correctly updated to use the newStateObjectTypereceiver type.
40-40: LGTM!The
Validatemethod has been correctly updated to use the newStateObjectTypereceiver type.
85-85: LGTM!The
ValidateObjectUpdatemethod has been correctly updated to use the newStateObjectTypereceiver type andStateObjectUpdateparameter type, maintaining consistency with the new naming convention.
Line range hint
1-100: Code style looks good!The code in this file conforms to the Uber Golang style guide. No deviations were found.
schema/diff/state_object_diff.go (5)
5-8: LGTM!The renaming of
ObjectTypeDifftoStateObjectTypeDiffimproves clarity and aligns with the PR objective. The struct fields remain unchanged, preserving the functionality.
42-43: LGTM!The changes to the
compareObjectTypefunction signature and return type are consistent with the renaming ofObjectTypeDifftoStateObjectTypeDiff. The function logic remains unchanged, preserving the functionality.
104-104: LGTM!The change to the
Emptymethod to operate on theStateObjectTypeDifftype is consistent with the renaming. The method logic remains unchanged, preserving the functionality.
110-110: LGTM!The change to the
HasCompatibleChangesmethod to operate on theStateObjectTypeDifftype is consistent with the renaming. The method logic remains unchanged, preserving the functionality.
Line range hint
1-141: Code style looks good!The code in this file conforms to the Uber Golang style guide. It is well-structured, readable, and follows consistent naming conventions. The comments are clear and concise.
schema/testing/statesim/object_coll.go (12)
13-13: LGTM!The comment update accurately reflects the transition to state-specific object types, aligning with the PR objectives.
16-16: LGTM!The type change from
schema.ObjectTypetoschema.StateObjectTypefor theobjectTypefield aligns with the PR objectives of enhancing type specificity for state management.
18-18: LGTM!Updating the
objectsfield to useschema.StateObjectUpdateas the value type is in line with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
19-19: LGTM!Modifying the
updateGenfield to generateschema.StateObjectUpdateinstead ofschema.ObjectUpdatealigns with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
24-24: LGTM!Updating the
NewObjectCollectionfunction signature to acceptschema.StateObjectTypeinstead ofschema.ObjectTypeis in line with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
25-25: LGTM!Modifying the
objectsvariable to useschema.StateObjectUpdateas the value type aligns with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
26-26: LGTM!Updating the
updateGenvariable to useschematesting.StateObjectUpdateGeninstead ofschematesting.ObjectUpdateGenis in line with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
43-43: LGTM!Modifying the
ApplyUpdatemethod signature to acceptschema.StateObjectUpdateinstead ofschema.ObjectUpdatealigns with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
109-109: LGTM!Updating the
UpdateGenmethod signature to return a generator ofschema.StateObjectUpdateinstead ofschema.ObjectUpdateis in line with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
115-115: LGTM!Modifying the
AllStatemethod signature to accept a function that takesschema.StateObjectUpdateinstead ofschema.ObjectUpdatealigns with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
116-116: LGTM!Updating the
objects.Scanmethod callback to useschema.StateObjectUpdateinstead ofschema.ObjectUpdateis in line with the PR objectives of transitioning to state-specific types for enhanced clarity in state management.
121-123: LGTM!The following changes align with the PR objectives of transitioning to state-specific types for enhanced clarity in state management:
- Updating the
GetObjectmethod signature to returnschema.StateObjectUpdateinstead ofschema.ObjectUpdate.- Modifying the
ObjectTypemethod signature to returnschema.StateObjectTypeinstead ofschema.ObjectType.- Updating the comments for the
GetObjectmethod to mention "StateObjectUpdate".Also applies to: 129-129
schema/diff/diff.go (6)
7-8: LGTM!The renaming of
AddedObjectTypestoAddedStateObjectTypesand the corresponding type change to[]schema.StateObjectTypealign well with the PR objective to enhance clarity by using more specific state-related types.
10-11: LGTM!The renaming of
ChangedObjectTypestoChangedStateObjectTypesand the corresponding type change to[]StateObjectTypeDiffalign well with the PR objective to enhance clarity by using more specific state-related types.
13-14: LGTM!The renaming of
RemovedObjectTypestoRemovedStateObjectTypesand the corresponding type change to[]schema.StateObjectTypealign well with the PR objective to enhance clarity by using more specific state-related types.
44-52: LGTM!The changes in this code segment, such as replacing
oldSchema.ObjectTypeswitholdSchema.StateObjectTypes,newSchema.LookupObjectTypewithnewSchema.LookupStateObjectType,diff.RemovedObjectTypeswithdiff.RemovedStateObjectTypes, anddiff.ChangedObjectTypeswithdiff.ChangedStateObjectTypes, align well with the renaming of object types to state object types. The lookup methods and diff fields have been updated consistently.
57-60: LGTM!The changes in this code segment, such as replacing
newSchema.ObjectTypeswithnewSchema.StateObjectTypes,oldSchema.LookupObjectTypewitholdSchema.LookupStateObjectType, anddiff.AddedObjectTypeswithdiff.AddedStateObjectTypes, align well with the renaming of object types to state object types. The lookup methods and diff fields have been updated consistently.
Line range hint
90-105: LGTM!The changes in this code segment, such as replacing
m.AddedObjectTypeswithm.AddedStateObjectTypes,m.ChangedObjectTypeswithm.ChangedStateObjectTypes, andm.RemovedObjectTypeswithm.RemovedStateObjectTypes, align well with the renaming of object types to state object types. TheEmptyandHasCompatibleChangesmethods have been updated consistently.schema/appdata/data.go (1)
134-134: LGTM! Verify the impact of this change.The change from
[]schema.ObjectUpdateto[]schema.StateObjectUpdatefor theUpdatesfield inObjectUpdateDatastruct aligns well with the stated PR objectives of enhancing type specificity and clarity in handling state management. The code change itself looks good.However, since this is a breaking change, please ensure that all code locations that use the
ObjectUpdateDatastruct have been updated to handle the new[]schema.StateObjectUpdatetype for theUpdatesfield. Run the following script to verify:Verification successful
Verification Successful: Change to
ObjectUpdateDataStruct Propagated CorrectlyThe transition from
[]schema.ObjectUpdateto[]schema.StateObjectUpdatefor theUpdatesfield in theObjectUpdateDatastruct has been successfully propagated across the codebase. All usages ofObjectUpdateDatareflect this change, and no issues were found with unrelated occurrences ofschema.ObjectUpdate.
- The
ObjectUpdateDatastruct is consistently used withStateObjectUpdatein various files.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all usages of `ObjectUpdateData` struct are updated to handle the new type. # Test 1: Search for `ObjectUpdateData` struct usages. # Expect: Only occurrences with `StateObjectUpdate` type for `Updates` field. rg --type go $'ObjectUpdateData' -A 5 # Test 2: Search for `schema.ObjectUpdate` usages. # Expect: Only occurrences unrelated to `ObjectUpdateData` struct. rg --type go $'schema\.ObjectUpdate'Length of output: 9805
schema/module_schema.go (6)
60-66: LGTM!The changes to the
ValidateObjectUpdatefunction signature and internal type handling align with the broader refactoring to transition from using general object types to more specific state-related types. The modifications ensure that the validation logic aligns with the new type definitions.
94-101: LGTM!The renaming of the
LookupObjectTypemethod toLookupStateObjectTypeand the corresponding changes to the return type align with the broader refactoring to transition fromObjectTypetoStateObjectType. The modifications are consistent with the goal of distinguishing between different categories of object types.
122-124: LGTM!The renaming of the
ObjectTypesmethod toStateObjectTypesand the corresponding changes to the parameter type of the callback function align with the broader refactoring to transition fromObjectTypetoStateObjectType. The modifications are consistent with the goal of distinguishing between different categories of object types.
144-145: LGTM!The changes to the
ObjectTypesfield in themoduleSchemaJsonstruct to expect a slice ofStateObjectTypeinstead ofObjectTypealign with the broader refactoring to transition from using general object types to more specific state-related types. The modifications ensure that the JSON marshaling structure reflects the new type definitions.
154-154: LGTM!The changes to the
MarshalJSONmethod to useStateObjectTypesinstead ofObjectTypesalign with the broader refactoring to transition from using general object types to more specific state-related types. The modifications ensure that the JSON marshaling logic reflects the new type definitions.
60-66: Conforms to the Uber Golang style guide.The code segments adhere to the Uber Golang style guide in terms of naming conventions, function signatures, and struct field definitions. No deviations from the style guide are observed in the provided code segments.
Also applies to: 94-101, 122-124, 144-145, 154-154
schema/state_object_test.go (16)
Line range hint
8-16: LGTM!The change from
ObjectTypetoStateObjectTypeenhances clarity and the field definition is valid.
Line range hint
18-29: Looks good!The change to
StateObjectTypewith valid key field definitions is approved.
Line range hint
31-43: Approved.The change to
StateObjectTypewith valid value field definitions looks good.
Line range hint
45-60: Change approved.The transition to
StateObjectTypewith valid key and value field definitions is good.
64-64: LGTM.Updating the
objectTypefield toStateObjectTypein the test struct is consistent with the new type definitions.
Line range hint
74-83: Test case looks good.Using
StateObjectTypein the "empty object type name" test case is consistent with the new type definition. It's important to validate the behavior when the object type name is empty.
Line range hint
87-97: Approved.Using
StateObjectTypein the "invalid key field" test case is consistent with the new type definition. Validating the behavior when a key field has an invalid definition is crucial.
Line range hint
100-109: Change looks good.Using
StateObjectTypein the "invalid value field" test case is consistent with the new type definition. Testing the behavior when a value field has an invalid definition is important.
112-114: Test case approved.Using
StateObjectTypein the "no fields" test case is consistent with the new type definition. Validating the behavior when an object type has no fields defined is a good edge case to cover.
Line range hint
117-134: LGTM.Using
StateObjectTypein the "duplicate field" test case is consistent with the new type definition. Testing the behavior when an object type has a duplicate field name is crucial for maintaining data integrity.
Line range hint
153-164: Test case looks good.Using
StateObjectTypein the "nullable key field" test case is consistent with the new type definition. Validating that key fields cannot be nullable is crucial for maintaining data integrity and uniqueness.
Line range hint
167-177: Change approved.Using
StateObjectTypein the "float32 key field" test case is consistent with the new type definition. Testing that float32 is an invalid key field type is important for maintaining data integrity and ensuring key fields support uniqueness and equality comparison.
Line range hint
180-190: LGTM.Using
StateObjectTypein the "float64 key field" test case is consistent with the new type definition. Validating that float64 is an invalid key field type, similar to float32, is important for maintaining data integrity and ensuring key fields support uniqueness and equality comparison.
Line range hint
193-203: Test case approved.Using
StateObjectTypein the "json key field" test case is consistent with the new type definition. Testing that JSON is an invalid key field type is crucial, as complex types like JSON are not suitable for keys and don't support efficient equality comparison.
225-225: Changes look good.Updating the
objectTypefields toStateObjectTypeandobjectfields toStateObjectUpdatein theTestObjectType_ValidateObjectUpdatetest cases is consistent with the transition to state-specific types. The test cases cover important scenarios for validating object updates, ensuring the correctness of theValidateObjectUpdatemethod.Also applies to: 226-226, 232-236, 241-245, 250-254, 259-264
Line range hint
1-288: Overall, the changes inschema/state_object_test.golook great!The transition from
ObjectTypetoStateObjectTypeandObjectUpdatetoStateObjectUpdatealigns perfectly with the PR objective of enhancing clarity and reducing confusion. The changes are consistently applied throughout the file, and the test cases cover a wide range of scenarios, ensuring the correctness of theValidateandValidateObjectUpdatemethods.The test cases validate important aspects such as empty object type
indexer/postgres/select.go (2)
Line range hint
150-214: Verify the function usage.The changes to the
readRowfunction look good and align with the PR objective of renamingObjectTypetoStateObjectType. However, ensure that the return type change is thoroughly tested to confirm that it behaves as expected, and that all function calls toreadRowhave been updated to handle the new return type.Run the following script to verify the function usage:
Verification successful
The usage of the
readRowfunction inview.goandselect.goappears to handle the new return type correctly. However, to ensure thorough verification, we need to check the calling function inselect.goto confirm it expects the new return type. Let's run a script to identify the calling function and verify its handling of the return type.
Let's refine our approach to identify the function in
select.gothat callsreadRowand verify its handling of the return type.
To ensure the calling function in
select.gocorrectly handles the new return type fromreadRow, let's capture the full function definition.
The function in
select.gothat callsreadRowcorrectly handles the new return type ofschema.StateObjectUpdate,bool, anderror. The changes are consistent with the PR objectives and do not introduce any issues.
- The function usage in
select.gois correctly aligned with the new return type ofreadRow.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `readRow` handle the new return type. # Test: Search for the function usage. Expect: No type mismatches. rg --type go -A 5 $'readRow\('Length of output: 998
Script:
#!/bin/bash # Description: Verify the calling function of `readRow` in `select.go` to ensure it expects the new return type. # Find the function that calls `readRow` in `select.go` and check its return type handling. rg --type go -A 10 'return tm.readRow(row)' indexer/postgres/select.goLength of output: 72
Script:
#!/bin/bash # Description: Search for the function definition in `select.go` that contains the `readRow` call. # Find the function definition that includes the `readRow` call. rg --type go -A 20 'func ' indexer/postgres/select.go | rg -B 5 'readRow'Length of output: 492
Script:
#!/bin/bash # Description: Capture the full function definition in `select.go` that includes the `readRow` call. # Find the full function definition that includes the `readRow` call. rg --type go -A 30 'func ' indexer/postgres/select.go | rg -B 10 -A 20 'readRow'Length of output: 1498
Line range hint
73-87: Verify the function usage.The changes to the
getfunction look good and align with the PR objective of renamingObjectTypetoStateObjectType. However, ensure that the return type change is thoroughly tested to confirm that it behaves as expected, and that all function calls togethave been updated to handle the new return type.Run the following script to verify the function usage:
Verification successful
Return Type Change Verified for
getFunctionThe return type change from
schema.ObjectUpdatetoschema.StateObjectUpdatein thegetfunction is correctly handled in the codebase. TheGetObjectmethod, which exposes this functionality, is used in a manner that appropriately checks for errors and object existence.
- Verified usage in
schema/testing/statesim/object_coll_diff.go.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `get` handle the new return type. # Test: Search for the function usage. Expect: No type mismatches. rg --type go -A 5 $'get\('Length of output: 32402
Script:
#!/bin/bash # Description: Verify all function calls to `objectView.get` handle the new return type. # Test: Search for the function usage. Expect: No type mismatches. rg --type go -A 5 $'get('Length of output: 85
Script:
#!/bin/bash # Description: Verify all function calls to `objectView.get` handle the new return type. # Test: Search for the function usage. Expect: No type mismatches. rg --type go -A 5 $'objectView.get\\('Length of output: 38
Script:
#!/bin/bash # Description: Search for any usage of `objectView` to identify potential indirect calls to the `get` method. # Test: Search for `objectView` usage. Expect: Identify contexts where `get` might be called indirectly. rg --type go -A 5 $'objectView'Length of output: 1815
Script:
#!/bin/bash # Description: Verify all function calls to `objectView.GetObject` handle the new return type. # Test: Search for the function usage. Expect: No type mismatches. rg --type go -A 5 $'GetObject\\('Length of output: 1934
schema/module_schema_test.go (16)
Line range hint
18-25: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
33-40: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
48-57: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
88-89: LGTM!The renaming of
objectUpdateparameter type fromObjectUpdatetoStateObjectUpdatein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
94-102: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
104-107: LGTM!The renaming of
ObjectUpdatetoStateObjectUpdatein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
113-121: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
123-126: LGTM!The renaming of
ObjectUpdatetoStateObjectUpdatein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
131-143: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
146-149: LGTM!The renaming of
ObjectUpdatetoStateObjectUpdatein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
180-187: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
190-191: LGTM!The renaming of
LookupObjectTypetoLookupStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
203-211: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
Line range hint
213-221: LGTM!The renaming of
ObjectTypetoStateObjectTypein this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
265-268: LGTM!The renaming of
ObjectTypestoStateObjectTypesin this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.
277-280: LGTM!The renaming of
ObjectTypestoStateObjectTypesin this test case aligns with the overall refactoring goal of transitioning to more specific state-related types. The change looks good.schema/diff/state_object_diff_test.go (2)
Line range hint
10-145: LGTM!The test cases have been comprehensively updated to cover the changes in the
compareObjectTypefunction. The test cases cover all the important scenarios and edge cases, and use thereflect.DeepEqualfunction to compare the expected and actual values, which is a good practice. The test cases also verify theHasCompatibleChangesfunction, which is important to ensure that the changes are compatible.
Line range hint
147-249: LGTM!The test cases comprehensively cover the
compareFieldsfunction. The test cases cover all the important scenarios and edge cases, and use thereflect.DeepEqualfunction to compare the expected and actual values, which is a good practice.schema/diff/diff_test.go (14)
Line range hint
21-29: LGTM!The test case correctly compares two identical
schema.StateObjectTypeinstances and expects an empty diff. The transition fromObjectTypetoStateObjectTypeis consistent.
Line range hint
36-47: LGTM!The test case correctly compares an empty schema with a schema containing one
schema.StateObjectTypeand expects a diff with one added state object type. The transition fromObjectTypetoStateObjectTypeis consistent.
Line range hint
52-64: LGTM!The test case correctly compares a schema containing one
schema.StateObjectTypewith an empty schema and expects a diff with one removed state object type. The transition fromObjectTypetoStateObjectTypeis consistent.
Line range hint
69-89: LGTM!The test case correctly compares two
schema.StateObjectTypeinstances with different key fields and expects a diff with one changed state object type containing the key fields diff. The transition fromObjectTypetoStateObjectTypeis consistent.
Line range hint
93-112: LGTM!The test case correctly compares two
schema.StateObjectTypeinstances with different value fields and expects a diff with one changed state object type containing the value fields diff. The transition fromObjectTypetoStateObjectTypeis consistent.
Line range hint
116-135: LGTM!The test case correctly compares two
schema.StateObjectTypeinstances with different value fields and expects a diff with one changed state object type containing the value fields diff. The transition fromObjectTypetoStateObjectTypeis consistent.
Line range hint
139-158: LGTM!The test case correctly compares two
schema.StateObjectTypeinstances with reordered key fields and expects a diff with one changed state object type containing the old and new order of key fields. The transition fromObjectTypetoStateObjectTypeis consistent.
Line range hint
162-198: LGTM!The test case correctly compares two schemas with different state object types and enum types. It expects a diff with one changed state object type containing the value fields diff and one added enum type. The transition from
ObjectTypetoStateObjectTypeis consistent.
Line range hint
204-237: LGTM!The test case correctly compares two schemas with different state object types and enum types. It expects a diff with one changed state object type containing the value fields diff and one removed enum type. The transition from
ObjectTypetoStateObjectTypeis consistent.
Line range hint
240-257: LGTM!The test case correctly compares two schemas with different enum types and expects a diff with one changed enum type containing the added enum value.
Line range hint
260-277: LGTM!The test case correctly compares two schemas with different enum types and expects a diff with one changed enum type containing the removed enum value.
Line range hint
280-312: LGTM!The test case correctly compares two schemas with switched object type and enum type names. It expects a diff with one removed and one added state object type, and one removed and one added enum type. The transition from
ObjectTypetoStateObjectTypeis consistent.
Line range hint
1-345: The unit test code provides sufficient coverage.The test cases cover various scenarios such as no change, object type added/removed/changed, enum type added/removed, and enum value added/removed. They also cover scenarios with compatible and incompatible changes. This provides a comprehensive coverage for the
CompareModuleSchemasfunction and the related diff types.
Line range hint
1-345: The code adheres to the Uber Go Style Guide.The code follows the basic Go style conventions such as using camelCase for variable and function names, and using uppercase for exported names. It uses proper indentation and spacing, and uses meaningful and concise names for variables and functions. There are no major deviations from the Uber Go Style Guide.
schema/decoding/decoding_test.go (6)
Line range hint
32-50: LGTM!The renaming of
expectedBankandexpectedOneto useschema.StateObjectUpdatealigns with the broader refactoring and is necessary for the test case to pass.Also applies to: 59-61
87-89: LGTM!The renaming of
expectedOneto useschema.StateObjectUpdatealigns with the broader refactoring and is necessary for the test case to pass.
Line range hint
111-125: LGTM!The renaming of
expectedandexpectedOneto useschema.StateObjectUpdatealigns with the broader refactoring and is necessary for the test case to pass.Also applies to: 133-135
160-162: LGTM!The renaming of
expectedOneto useschema.StateObjectUpdatealigns with the broader refactoring and is necessary for the test case to pass.
Line range hint
403-426: LGTM!The renaming of the
KVDecoderreturn type to useschema.StateObjectUpdatealigns with the broader refactoring and is necessary for the module codec to be compatible with the refactored codebase.
454-461: LGTM!The renaming of the
KVDecoderreturn type to useschema.StateObjectUpdatealigns with the broader refactoring and is necessary for the module codec to be compatible with the refactored codebase.
| @@ -119,7 +119,7 @@ func (a *Simulator) BlockDataGenN(minUpdatesPerBlock, maxUpdatesPerBlock int) *r | |||
| }) | |||
| } | |||
|
|
|||
| func (a *Simulator) formatUpdateKey(moduleName string, update schema.ObjectUpdate) string { | |||
| func (a *Simulator) formatUpdateKey(moduleName string, update schema.StateObjectUpdate) string { | |||
There was a problem hiding this comment.
LGTM, but consider returning the error.
The change in the function signature from schema.ObjectUpdate to schema.StateObjectUpdate aligns well with the PR objective to transition to more specific state-related types. The logic of the function remains unchanged, so this is a non-breaking change.
However, the function uses panic to handle errors from GetModule and GetObjectCollection, which is not recommended in a library intended for reuse. Consider returning the error instead to allow the caller to handle it appropriately.
Apply this diff to return the error:
-func (a *Simulator) formatUpdateKey(moduleName string, update schema.StateObjectUpdate) string {
+func (a *Simulator) formatUpdateKey(moduleName string, update schema.StateObjectUpdate) (string, error) {
mod, err := a.state.GetModule(moduleName)
if err != nil {
- panic(err)
+ return "", err
}
objColl, err := mod.GetObjectCollection(update.TypeName)
if err != nil {
- panic(err)
+ return "", err
}
ks := fmt.Sprintf("%s:%s:%s", moduleName, update.TypeName, schematesting.ObjectKeyString(objColl.ObjectType(), update.Key))
- return ks
+ return ks, nil
}Then, update the callers of formatUpdateKey to handle the returned error.
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.
| func (a *Simulator) formatUpdateKey(moduleName string, update schema.StateObjectUpdate) string { | |
| func (a *Simulator) formatUpdateKey(moduleName string, update schema.StateObjectUpdate) (string, error) { | |
| mod, err := a.state.GetModule(moduleName) | |
| if err != nil { | |
| return "", err | |
| } | |
| objColl, err := mod.GetObjectCollection(update.TypeName) | |
| if err != nil { | |
| return "", err | |
| } | |
| ks := fmt.Sprintf("%s:%s:%s", moduleName, update.TypeName, schematesting.ObjectKeyString(objColl.ObjectType(), update.Key)) | |
| return ks, nil | |
| } |
|
@aaronc , need to fix the lint issue |
Description
This does a bunch of renaming of
schema.ObjectTypetoschema.StateObjectType- the reasoning being that in the context of VMs and programming in general,Objecthas a much more generic meaning than this specific meaning we have here of some data in state represented by key-value pair fields.I don't love needing to do these sorts of renamings, but I think this is hopefully less confusing... Also open to sticking with the existing name if it's not a problem or changing this to an alternate name such as
CollectionType.Either way if we are going to do a renaming, I'd rather get the breakage done with ASAP.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!in the type prefix if API or client breaking changeCHANGELOG.mdReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
Please see Pull Request Reviewer section in the contributing guide for more information on how to review a pull request.
I have...
Summary by CodeRabbit
ObjectTypetoStateObjectTypeandObjectUpdatetoStateObjectUpdate.