update launch command; adding celestia codec, several bug fix #116
Conversation
WalkthroughThe changes in this pull request involve significant updates to the configuration settings and functionality of the Launch Tools within the 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
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #116 +/- ##
=======================================
Coverage 48.61% 48.61%
=======================================
Files 57 57
Lines 4229 4229
=======================================
Hits 2056 2056
Misses 1744 1744
Partials 429 429
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
contrib/launchtools/utils/address.go (1)
17-19: LGTM! Consider adding a comment for consistency.The new
CelestiaAddressCodecfunction is correctly implemented and follows the existing pattern in the file. It aligns with the PR objective of incorporating the Celestia codec.For consistency with the
L1AddressCodecfunction, consider adding a brief comment explaining the purpose of this function:+// CelestiaAddressCodec returns a new Bech32 codec for Celestia addresses func CelestiaAddressCodec() address.Codec { return authcodec.NewBech32Codec("celestia") }contrib/launchtools/cmd.go (1)
Line range hint
26-115: Consider refactoring for improved readability and maintainability.While the
LaunchCmdfunction is well-structured, consider the following improvements:
- Break down the function into smaller, more focused functions to improve readability and maintainability.
- Use more specific error messages to aid in debugging.
- Consider using a proper logging framework instead of
fmt.Fprintffor error output.Here's a high-level example of how you might refactor this function:
func LaunchCmd(...) *cobra.Command { cmd := &cobra.Command{ // ... (command details) RunE: runLaunchCmd, } // ... (flag setup) return cmd } func runLaunchCmd(cmd *cobra.Command, args []string) error { config, err := setupConfig(cmd) if err != nil { return err } launcher, err := setupLauncher(cmd, config) if err != nil { return err } if err := runLauncherSteps(launcher, config); err != nil { return err } return outputArtifacts(cmd, launcher, config) } // Implement setupConfig, setupLauncher, runLauncherSteps, and outputArtifacts as separate functionsThis refactoring would make the code more modular and easier to maintain.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
- contrib/launchtools/README.md (2 hunks)
- contrib/launchtools/cmd.go (1 hunks)
- contrib/launchtools/config.go (9 hunks)
- contrib/launchtools/steps/genesis.go (0 hunks)
- contrib/launchtools/utils/address.go (1 hunks)
💤 Files with no reviewable changes (1)
- contrib/launchtools/steps/genesis.go
🧰 Additional context used
🔇 Additional comments (16)
contrib/launchtools/utils/address.go (1)
17-19: Verify the usage of the new CelestiaAddressCodec function.The addition of
CelestiaAddressCodecexpands the address codec functionality to include Celestia addresses. This aligns with the PR objectives and is a well-contained change.To ensure this new function is being used appropriately, please run the following script to check its usage across the codebase:
This will help verify that the new function is being utilized as intended and that there are no outstanding tasks related to Celestia address handling.
✅ Verification successful
CelestiaAddressCodec Usage Verified
The
CelestiaAddressCodecfunction is used incontrib/launchtools/config.go. No related TODOs or FIXMEs were found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the usage of CelestiaAddressCodec function # Test: Search for CelestiaAddressCodec usage echo "Searching for CelestiaAddressCodec usage:" rg "CelestiaAddressCodec\(\)" --type go # Test: Check if there are any TODOs or FIXMEs related to Celestia address handling echo "Checking for TODOs or FIXMEs related to Celestia addresses:" rg "TODO|FIXME" --type go | rg -i "celestia.*address"Length of output: 469
contrib/launchtools/README.md (6)
58-61: LGTM. Verify L1-only address design for submitters.The
output_submitterandbatch_submitterconfigurations have been updated to usel1_addressinstead ofaddress. This change is consistent with the new L1/L2 address distinction.Please confirm:
- The intention to have only L1 addresses for these roles.
- That all code referencing these addresses has been updated accordingly.
- Consider adding a comment explaining why these roles only require L1 addresses, if this is indeed the intended configuration.
To verify the impact and usage, run the following script:
✅ Verification successful
Verified L1-only address implementation for submitters.
No additional references tooutput_submitter.addressorbatch_submitter.addresswere found in the codebase, confirming that the renaming tol1_addressis correctly implemented and scoped.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usage of output submitter and batch submitter addresses in the code echo "Searching for output submitter address usage:" rg "output_submitter.*address" --type go echo "Searching for batch submitter address usage:" rg "batch_submitter.*address" --type goLength of output: 1673
31-32: LGTM. Verify impact on dependent systems.The
chain_idandrpc_urlhave been updated consistently to reflect the new chain "initiation-2". This change looks good, but it's important to ensure that all dependent systems and documentation are updated accordingly.To verify the impact, run the following script:
✅ Verification successful
Verification Successful
No occurrences of the old
chain_id("initiation-1") orrpc_url("https://rpc.initiation-1.initia.xyz:443") were found in the codebase. Changes are verified.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for occurrences of the old chain ID and RPC URL echo "Searching for old chain ID (initiation-1):" rg "initiation-1" --type md --type go --type json echo "Searching for old RPC URL:" rg "https://rpc.initiation-1.initia.xyz:443" --type md --type go --type jsonLength of output: 284
53-54: ```shell
#!/bin/bashCorrected search for bridge_executor address usage in Go files
echo "Searching for bridge_executor address usage in Go files:"
rg "bridge_executor.*address" --type go--- Line range hint `67-80`: **LGTM. Verify impact on system initialization.** The `genesis_accounts` section has been updated to remove entries for `output_submitter` and `batch_submitter`. This change is consistent with the modifications in the `system_keys` section. Please ensure: 1. The removal of these accounts from the genesis configuration doesn't negatively impact the system's initialization or operation. 2. Any code or processes that previously relied on these accounts being present in the genesis state have been updated accordingly. 3. The documentation reflects this change in the genesis account setup. To verify the impact, run the following script: <details> <summary>✅ Verification successful</summary> <!-- [monologue] [task finalize_verification_1/1] Finalize the verification based on the shell script output. [observations] - The corrected shell script did not find any references to `output_submitter` and `batch_submitter` in genesis-related Go code. - This indicates that their removal from the `genesis_accounts` section does not affect system initialization. [analysis] - The absence of references suggests that these accounts are no longer in use and their removal is safe. - No further action is needed unless there are non-Go files that might reference these accounts, which is unlikely based on the context. [actions] - Conclude the verification by approving the changes and confirming that the removal does not impact system initialization. --> **Verified: Removal of `output_submitter` and `batch_submitter`** No references to `output_submitter` and `batch_submitter` were found in genesis-related Go code, ensuring that their removal does not impact system initialization. </details> <details> <summary>🏁 Scripts executed</summary> The following scripts were executed for the analysis: Script: ```shell #!/bin/bash # Search for references to output_submitter and batch_submitter in genesis-related code echo "Searching for output_submitter in genesis-related code:" rg "output_submitter" --type go | rg "genesis" echo "Searching for batch_submitter in genesis-related code:" rg "batch_submitter" --type go | rg "genesis"Length of output: 1673
Script:
#!/bin/bash # Corrected script to search for references to output_submitter and batch_submitter in genesis-related Go code echo "Searching for output_submitter in genesis-related Go code:" rg "output_submitter" --type go | rg "genesis" echo "Searching for batch_submitter in genesis-related Go code:" rg "batch_submitter" --type go | rg "genesis"Length of output: 340
64-65: LGTM. Verify design decision for identical L1 and L2 addresses for challenger.The
challengerconfiguration now includes bothl1_addressandl2_address, similar to the bridge executor. Both addresses are currently set to the same value.Please address the following:
- Confirm if having identical L1 and L2 addresses for the challenger is intentional.
- Ensure that all code referencing the challenger's address has been updated to use the correct address (L1 or L2) based on the context.
- Consider adding a comment explaining the reason for identical addresses, if this is the intended configuration.
- Verify if this change is consistent with the overall system design and the roles of the challenger in both L1 and L2 contexts.
To verify the impact and usage, run the following script:
41-45: LGTM. Verify new parameters and type changes.The changes in the
op_bridgesection improve readability and introduce new parameters:
- Time intervals are now in a human-readable format (e.g., "1h0m0s", "168h0m0s").
output_submission_start_heightis now an integer instead of a string.- New parameters
batch_submission_targetandenable_oraclehave been added.These changes look good, but please ensure:
- The code handling these parameters can parse the new time format.
- The type change for
output_submission_start_heightis handled correctly in the code.- The new parameters are properly implemented and documented in the codebase.
To verify the impact, run the following script:
contrib/launchtools/cmd.go (1)
99-99: Confirm consistency of artifact file name change.The file name in the output message has been changed from "artifact.json" to "artifacts.json". This change appears to be intentional and aligns with the PR objectives of updating the launch command.
To ensure consistency across the codebase, let's verify if this change is reflected in other relevant files:
This will help us confirm if the change has been consistently applied throughout the project.
✅ Verification successful
Artifact file name change is consistent across the codebase.
All occurrences of "artifact.json" have been successfully updated to "artifacts.json".
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for occurrences of both "artifact.json" and "artifacts.json" in the codebase. echo "Searching for 'artifact.json':" rg -i "artifact\.json" echo "\nSearching for 'artifacts.json':" rg -i "artifacts\.json"Length of output: 425
contrib/launchtools/config.go (8)
14-14: Imports added correctly.The new imports are necessary for the added functionality involving address codecs and cryptography.
Also applies to: 21-21
80-82: Ensure 'BatchSubmissionTarget' is properly initialized before use.Confirm that
i.OpBridge.BatchSubmissionTargetis set correctly before callingSystemKeys.Finalizeto avoid potential issues with uninitialized variables.
310-313: Skipping accounts with emptyL2Addressis appropriate.The added check prevents unnecessary processing of accounts without an
L2Address, enhancing efficiency.
370-376:deriveAddressfunction updated to acceptaddress.Codec.This change allows address derivation to be flexible based on the provided codec, improving the function's reusability.
378-386: ImplementedderiveL1L2Addressesfunction correctly.The new function efficiently derives both L1 and L2 addresses from a given mnemonic.
387-399:deriveAddressWithChainTypefunction handles chain types effectively.The function selects the appropriate codec based on
chainType, ensuring correct address derivation for different chains.
408-408: Proper error handling inderiveAddressBz.Errors during private key derivation are correctly wrapped, and the function returns the public key address as expected.
Also applies to: 412-412
Line range hint
415-521: UpdatedSystemKeys.Finalizeto accommodatebatchSubmissionTarget.The method now properly initializes system accounts using the new address derivation functions and the provided batch submission target.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
x/ophost/keeper/msg_server.go (5)
Line range hint
350-388: Refactor duplicated logic in update methods to improve maintainabilityThe methods
UpdateProposer,UpdateChallenger,UpdateBatchInfo,UpdateOracleConfig, andUpdateMetadataall share similar code structures, including validation, permission checks, configuration updates, and event emission. Refactoring common logic into helper functions or a generic update handler can reduce code duplication and enhance maintainability.Consider creating a generic helper function to handle the common update logic:
func (ms MsgServer) updateBridgeConfig(ctx context.Context, reqAuthority string, bridgeId uint64, expectedAuthority string, updateFunc func(*types.BridgeConfig) error, eventType string, eventAttributes []sdk.Attribute) error { if ms.authority != reqAuthority && expectedAuthority != reqAuthority { return govtypes.ErrInvalidSigner.Wrapf("invalid authority; expected %s or %s, got %s", ms.authority, expectedAuthority, reqAuthority) } config, err := ms.GetBridgeConfig(ctx, bridgeId) if err != nil { return err } if err := updateFunc(&config); err != nil { return err } if err := ms.SetBridgeConfig(ctx, bridgeId, config); err != nil { return err } sdk.UnwrapSDKContext(ctx).EventManager().EmitEvent(sdk.NewEvent( eventType, eventAttributes..., )) return nil }Then, each update method can use this helper function, passing in the specific update logic and event details.
Also applies to: 395-434, 440-487, 489-516
Line range hint
489-516: Missing bridge hook call inUpdateOracleConfigUnlike other update methods,
UpdateOracleConfigdoes not invoke a bridge hook after updating the configuration. To maintain consistency and ensure that any necessary side effects are handled, consider adding a bridge hook call similar to other update methods.If a
BridgeOracleConfigUpdatedhook exists, you can add:if err := ms.Keeper.bridgeHook.BridgeOracleConfigUpdated(ctx, bridgeId, config); err != nil { return nil, err }This should be placed after updating
config.OracleEnabledand before setting the updated configuration.
Line range hint
519-538: Consider emitting an event after updating parameters inUpdateParamsIn
UpdateParams, after successfully updating the parameters, it would be beneficial to emit an event indicating that the parameters have changed. This can aid in tracking configuration changes and debugging.Add event emission:
sdk.UnwrapSDKContext(ctx).EventManager().EmitEvent(sdk.NewEvent( types.EventTypeUpdateParams, sdk.NewAttribute(types.AttributeKeyAuthority, req.Authority), ))
Line range hint
350-388: Potential nil pointer dereference when accessingfinalizedOutputIn
UpdateProposer, after callingGetLastFinalizedOutput, the code accessesfinalizedOutput.L2BlockNumberwithout checking iffinalizedOutputis nil. IfGetLastFinalizedOutputcan return a nilfinalizedOutput, this could lead to a runtime panic.Ensure that
finalizedOutputis not nil before accessing its fields:if finalizedOutput == nil { // Handle the nil case appropriately }Alternatively, adjust
GetLastFinalizedOutputto guarantee a non-nilfinalizedOutput.
Line range hint
440-487: Event attributes may contain outdated values after updating configIn
UpdateBatchInfo, after updatingconfig.BatchInfo, the event attributes usereq.NewBatchInfodirectly. If any modifications toconfig.BatchInfooccur within hooks or update functions, the event attributes might not reflect the current state. Consider using the updatedconfigobject when constructing event attributes.Use
config.BatchInfoin event attributes to ensure consistency:sdk.UnwrapSDKContext(ctx).EventManager().EmitEvent(sdk.NewEvent( types.EventTypeUpdateBatchInfo, sdk.NewAttribute(types.AttributeKeyBridgeId, strconv.FormatUint(bridgeId, 10)), sdk.NewAttribute(types.AttributeKeyBatchChainType, config.BatchInfo.ChainType.StringWithoutPrefix()), sdk.NewAttribute(types.AttributeKeyBatchSubmitter, config.BatchInfo.Submitter), // ... ))
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (2)
contrib/launchtools/README.md (1)
41-45: LGTM. Update documentation for new parameter.The changes to the
op_bridgesection improve readability and add new functionality:
- Time-based parameters now use a more human-readable format.
- The
enable_oracleparameter has been added.These changes look good and enhance the configuration.
Please ensure that the documentation is updated to explain the purpose and impact of the new
enable_oracleparameter.contrib/launchtools/utils/address.go (1)
39-81: Add unit tests for the new address derivation functions.The functions
DeriveL1Address,DeriveL2Address, andDeriveDAAddressare critical for address derivation and should be thoroughly tested to ensure they work correctly with various mnemonics and chain types.Would you like assistance in creating unit tests for these functions?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
- README.md (1 hunks)
- contrib/launchtools/README.md (2 hunks)
- contrib/launchtools/config.go (9 hunks)
- contrib/launchtools/steps/opbridge.go (1 hunks)
- contrib/launchtools/utils/address.go (3 hunks)
✅ Files skipped from review due to trivial changes (1)
- README.md
🚧 Files skipped from review as they are similar to previous changes (1)
- contrib/launchtools/config.go
🧰 Additional context used
🔇 Additional comments (6)
contrib/launchtools/README.md (4)
49-49: LGTM. Ensure consistent usage ofl2_address.The change from
addresstol2_addressfor the validator is correct and aligns with the L1/L2 address distinction.As noted in a previous review, please ensure that all references to the validator's address throughout the codebase have been updated to use
l2_addressconsistently.
Line range hint
68-81: LGTM. Genesis accounts updated consistently.The removal of entries for
output_submitterandbatch_submitterfrom thegenesis_accountssection aligns with the changes made in thesystem_keyssection. This change maintains consistency in the configuration.
53-54: LGTM. Verifyda_addressusage for batch submitter.The updates to address fields for various roles consistently apply the L1/L2 address distinction, improving clarity and specificity in the configuration. The changes look good overall.
Please verify the use of
da_addressfor the batch submitter:#!/bin/bash echo "Checking batch submitter address usage:" rg "batch.*submitter.*address" --type goEnsure that all relevant code has been updated to use
da_addressinstead ofl1_addressfor the batch submitter.Also applies to: 58-58, 61-61, 64-65
31-32: LGTM. Verify network upgrade implications.The
chain_idandrpc_urlhave been updated, likely as part of a network upgrade from "initiation-1" to "initiation-2". These changes look good.Please ensure that all related components and documentation are updated to reflect this network change. Run the following script to check for any remaining references to the old network:
✅ Verification successful
Verified removal of "initiation-1" references.
All instances of "initiation-1" have been successfully removed. The remaining references to "INITIA|CELESTIA" are unrelated to the network upgrade.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash echo "Searching for old network references:" rg "initiation-1" --type-not mdLength of output: 342
Script:
#!/bin/bash echo "Performing a comprehensive search for any variations of 'initiation-1':" rg -i "initiation-1" --type-not mdLength of output: 193
Script:
#!/bin/bash echo "Searching for 'INITIA|CELESTIA' references:" rg "INITIA\|CELESTIA" --type-not mdLength of output: 351
contrib/launchtools/steps/opbridge.go (1)
47-47: Verify the use of DAAddress for batch submissionThe change from
L1AddresstoDAAddressfor the batch submitter appears to be part of a larger architectural change. This modification aligns with updates in other files, particularly the addition of theDAAddressfield in theSystemAccountstruct inconfig.go.
- Please confirm that using
DAAddressinstead ofL1Addressfor the batch submitter is the intended behavior.- Consider adding a comment explaining the rationale behind this change, which will help future maintainers understand the distinction between L1 and DA addresses in this context.
- Ensure that this change is consistently applied across the codebase, particularly in any other locations where the batch submitter's address is used.
To help verify the consistency of this change, you can run the following script:
This will help identify any places where the old
L1Addressmight still be in use and confirm the newDAAddressis being used consistently.✅ Verification successful
BatchSubmitter address update verified
All instances of
BatchSubmitter.L1Addresshave been replaced withBatchSubmitter.DAAddress. The change is consistent across the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining uses of BatchSubmitter.L1Address and compare with BatchSubmitter.DAAddress usage echo "Occurrences of BatchSubmitter.L1Address:" rg "BatchSubmitter\.L1Address" --type go echo "\nOccurrences of BatchSubmitter.DAAddress:" rg "BatchSubmitter\.DAAddress" --type goLength of output: 434
contrib/launchtools/utils/address.go (1)
25-27: Verify the Bech32 prefix for Celestia addresses.Ensure that
"celestia"is the correct Bech32 prefix for Celestia addresses. Using an incorrect prefix can lead to invalid address generation.
| @@ -1,9 +1,17 @@ | |||
| package utils | |||
|
|
|||
| import ( | |||
| "github.com/pkg/errors" | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using the standard errors package instead of github.com/pkg/errors.
Starting from Go 1.13, the standard library's errors package provides error wrapping features like errors.Is, errors.As, and fmt.Errorf with %w. Using the standard package can reduce dependencies and streamline error handling.
| func DeriveDAAddress(mnemonic string, chainType ophosttypes.BatchInfo_ChainType) (string, error) { | ||
| var codec address.Codec | ||
| switch chainType { | ||
| case ophosttypes.BatchInfo_CHAIN_TYPE_INITIA: | ||
| codec = L1AddressCodec() | ||
| case ophosttypes.BatchInfo_CHAIN_TYPE_CELESTIA: | ||
| codec = CelestiaAddressCodec() | ||
| default: | ||
| return "", errors.New("unsupported chain type") | ||
| } | ||
| return deriveAddress(mnemonic, codec) | ||
| } |
There was a problem hiding this comment.
Improve error message for unsupported chain types.
Including the unsupported chain type in the error message can aid in debugging and provide clearer feedback.
Apply this diff to enhance the error message:
- return "", errors.New("unsupported chain type")
+ return "", errors.Errorf("unsupported chain type: %v", chainType)📝 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 DeriveDAAddress(mnemonic string, chainType ophosttypes.BatchInfo_ChainType) (string, error) { | |
| var codec address.Codec | |
| switch chainType { | |
| case ophosttypes.BatchInfo_CHAIN_TYPE_INITIA: | |
| codec = L1AddressCodec() | |
| case ophosttypes.BatchInfo_CHAIN_TYPE_CELESTIA: | |
| codec = CelestiaAddressCodec() | |
| default: | |
| return "", errors.New("unsupported chain type") | |
| } | |
| return deriveAddress(mnemonic, codec) | |
| } | |
| func DeriveDAAddress(mnemonic string, chainType ophosttypes.BatchInfo_ChainType) (string, error) { | |
| var codec address.Codec | |
| switch chainType { | |
| case ophosttypes.BatchInfo_CHAIN_TYPE_INITIA: | |
| codec = L1AddressCodec() | |
| case ophosttypes.BatchInfo_CHAIN_TYPE_CELESTIA: | |
| codec = CelestiaAddressCodec() | |
| default: | |
| return "", errors.Errorf("unsupported chain type: %v", chainType) | |
| } | |
| return deriveAddress(mnemonic, codec) | |
| } |
| func deriveAddress(mnemonic string, codec address.Codec) (string, error) { | ||
| addrBz, err := deriveAddressBz(mnemonic) | ||
| if err != nil { | ||
| return "", errors.Wrap(err, "failed to convert address to bech32") |
There was a problem hiding this comment.
Correct the error message to reflect the actual failure point.
The error message suggests a failure in converting to Bech32, but the error actually occurs during address byte derivation. Update the message for clarity.
Apply this diff to correct the error message:
- return "", errors.Wrap(err, "failed to convert address to bech32")
+ return "", errors.Wrap(err, "failed to derive address bytes")📝 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.
| return "", errors.Wrap(err, "failed to convert address to bech32") | |
| return "", errors.Wrap(err, "failed to derive address bytes") |
Description
Closes: #XXXX
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 changeReviewers 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.
I have...
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores