Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(store/v2): Add missing documents #22118

Merged
merged 1 commit into from
Oct 4, 2024
Merged

docs(store/v2): Add missing documents #22118

merged 1 commit into from
Oct 4, 2024

Conversation

cool-develope
Copy link
Contributor

@cool-develope cool-develope commented Oct 3, 2024

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...

  • included the correct type prefix in the PR title, you can find examples of the prefixes below:
  • confirmed ! in the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • reviewed "Files changed" and left comments if necessary
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • updated the relevant documentation or specification, including comments for documenting Go code
  • confirmed all CI checks have passed

Reviewers 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...

  • confirmed the correct type prefix in the PR title
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic, API design and naming, documentation is accurate, tests and test coverage

Summary by CodeRabbit

  • Documentation
    • Enhanced clarity on the root.Store type and its functionalities in the store/v2 documentation.
    • Added sections on state synchronization and migration details from store/v1 to store/v2.
    • Introduced new "Pruning" section in the commitment package documentation, detailing data management processes.
    • Updated storage package documentation to clarify the roles of various components and pruning processes.
    • Added new interfaces and methods to support enhanced functionalities in the migration and storage processes.

@cool-develope cool-develope requested review from kocubinski and a team as code owners October 3, 2024 21:35
Copy link
Contributor

coderabbitai bot commented Oct 3, 2024

📝 Walkthrough

Walkthrough

The pull request introduces significant updates to the documentation across several packages within the store/v2 module. Key modifications include the addition of new sections on state synchronization and data migration, as well as the introduction of interfaces for data pruning. Terminology corrections and clarifications enhance the understanding of functionalities related to the root.Store, MigrationManager, and the Pruner interface. Overall, these changes aim to improve the clarity and completeness of the documentation concerning the operational aspects of the store system.

Changes

File Path Change Summary
store/v2/README.md - New section on State Sync added.
- Migration details from store/v1 to store/v2 documented.
- Corrected terminology from Prune store keys to PruneStoreKeys.
store/v2/commitment/README.md - New sections on "Pruning" added, detailing the Pruner and PausablePruner interfaces.
- Reformatting of existing sections for clarity.
store/v2/migration/README.md - Introduced new file detailing the migration.Manager and its lazy migration process.
- Added methods for starting the migration process.
store/v2/storage/README.md - Enhanced clarity on the Pruner interface and Restore method operations.
- Restructured the Pruning section for better understanding.

Possibly related PRs

Suggested labels

C:Store, C:Simulations, C:Hubl, backport/v0.52.x

Suggested reviewers

  • kocubinski
  • lucaslopezf
  • akhilkumarpilli
  • facundomedica
  • sontrinh16

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (9)
store/v2/commitment/README.md (1)

31-35: Excellent addition of the Pruning section.

The new section on Pruning is well-written and provides valuable information about the process and implementation requirements. It aligns perfectly with the AI-generated summary and enhances the overall documentation.

Consider adding a brief explanation of what the PruningOption is, as it's mentioned but not defined. This would provide more context for readers unfamiliar with the concept.

store/v2/README.md (4)

45-47: LGTM: Improved clarity on pruning process

The correction of the method name to PruneStoreKeys and the added explanation about the pruning process enhance the documentation's accuracy and clarity.

Consider adding a brief note about when the actual data removal occurs, if that information is available. For example:
"The actual data removal is done by the pruning process of the underlying SS and SC, which typically occurs [insert timing or trigger for pruning]."


51-52: LGTM: Added Migration section

The new Migration section provides valuable information about the migration process from store/v1 to store/v2, which is crucial for users upgrading their systems.

Consider expanding this section slightly to include:

  1. A brief mention of why someone might need to migrate (e.g., "For users upgrading from store/v1...")
  2. Any high-level steps or considerations for the migration process.

This additional context could help users better understand the migration process without needing to immediately refer to the detailed documentation.


61-64: LGTM: Added State Sync section

The new State Sync section clearly states the responsibility boundary of root.Store and directs users to the appropriate documentation for more information.

To provide more context, consider expanding this section slightly:

  1. Add a brief explanation of what state sync is and why it's important.
  2. Mention which component is responsible for state sync if root.Store is not.

For example:
"State sync allows new nodes to quickly catch up to the current state of the blockchain. While the root.Store is NOT responsible for state sync, this crucial functionality is handled by [component name]. See Snapshots Manager for more details on implementation and usage."


57-57: Minor: Consider hyphenation of "asynchronous"

The static analysis tool suggests hyphenating "asynchronous" as "asynchron-ous". However, in modern usage, "asynchronous" is commonly written without a hyphen and is correct as is. You may choose to keep it as-is or add the hyphen based on your project's style guide.

🧰 Tools
🪛 LanguageTool

[uncategorized] ~57-~57: This expression is ususally spelled with a hyphen
Context: ...nd SC layers. This means pruning can be implementation specific, such as being synchronous or asynchron...

(SPECIFIC_HYPHEN)

store/v2/migration/README.md (2)

24-49: LGTM: Clear usage instructions with a minor suggestion

The usage section provides clear instructions on how to create and use the migration manager. The code snippets are well-formatted and informative.

Consider adding a brief example of how to call the Start method, including how to create and pass the context. This would provide a complete usage example for developers.


111-111: Add a newline character at the end of the file

To comply with Markdown best practices and resolve the static analysis hint, please add a newline character at the end of the file.

Apply this change to the end of the file:

 Alternatively, keeping store/v1 accessible for historical queries could be an option.
+
🧰 Tools
🪛 Markdownlint

111-111: null
Files should end with a single newline character

(MD047, single-trailing-newline)

store/v2/storage/README.md (2)

73-76: Excellent addition to the Pruning section!

The new content provides a clear and concise explanation of the pruning process and its implementation in the State Storage system. It introduces important concepts like the Pruner interface and PruningManager, which enhance the reader's understanding of the pruning mechanism.

To further improve clarity, consider adding a brief example or more details about the PruningOption mentioned in the last line. This could help readers better understand how pruning can be configured.


Line range hint 78-87: Great improvements to the State Sync section!

The modifications provide a clearer and more detailed explanation of the state sync process, particularly regarding the roles of snapshots.Manager and StorageStore. The expanded description of the Restore method is especially helpful in understanding its functionality.

To make this section even more comprehensive, consider adding a brief mention of how the snapshots.Manager creates snapshots, not just how it restores them. This would provide a complete picture of the state sync process.

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 5bed965 and bde0726.

📒 Files selected for processing (4)
  • store/v2/README.md (2 hunks)
  • store/v2/commitment/README.md (1 hunks)
  • store/v2/migration/README.md (1 hunks)
  • store/v2/storage/README.md (1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
store/v2/README.md (1)

Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"

store/v2/commitment/README.md (1)

Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"

store/v2/migration/README.md (1)

Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"

store/v2/storage/README.md (1)

Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"

🪛 LanguageTool
store/v2/README.md

[uncategorized] ~57-~57: This expression is ususally spelled with a hyphen
Context: ...nd SC layers. This means pruning can be implementation specific, such as being synchronous or asynchron...

(SPECIFIC_HYPHEN)

🪛 Markdownlint
store/v2/migration/README.md

111-111: null
Files should end with a single newline character

(MD047, single-trailing-newline)

🔇 Additional comments (7)
store/v2/README.md (2)

4-4: LGTM: Corrected link to ADR-065

The update to the relative path for the ADR-065 document improves the accuracy of the documentation.


58-58: LGTM: Added link to Pruning Manager documentation

The addition of the link to the Pruning Manager documentation provides a valuable resource for users seeking more detailed information about the pruning process.

store/v2/migration/README.md (4)

1-23: LGTM: Clear and informative introduction

The introduction and overview sections provide a concise and clear explanation of the migration manager's purpose and the migration process. The note about historical queries not being supported after migration is crucial information for users.


50-79: LGTM: Well-structured migration flow diagram

The migration flow section provides an excellent visual representation of the process using a mermaid sequence diagram. The diagram clearly illustrates the interactions between different components involved in the migration, making it easy for developers to understand the flow.


80-111: LGTM: Comprehensive key considerations

The key considerations section provides valuable information about the migration process, including its lazy nature, background operation, handling of failures, and impact on historical queries. This information is crucial for users to understand the implications of the migration process.

🧰 Tools
🪛 Markdownlint

111-111: null
Files should end with a single newline character

(MD047, single-trailing-newline)


1-111: LGTM: Well-structured and formatted document

The overall structure and formatting of the document are excellent. The use of clear headings, properly formatted code snippets, and the mermaid diagram enhances readability and makes the information easy to understand.

🧰 Tools
🪛 Markdownlint

111-111: null
Files should end with a single newline character

(MD047, single-trailing-newline)

store/v2/storage/README.md (1)

Line range hint 1-100: Overall excellent improvements to the documentation!

The changes made to this README file have significantly enhanced the clarity and completeness of the State Storage (SS) documentation. The additions to the Pruning and State Sync sections provide valuable insights into these processes, making the document more informative for users and developers.

The new content integrates well with the existing structure, maintaining consistency throughout the document. These improvements will undoubtedly help readers better understand the functionality and implementation of the State Storage system in the Cosmos SDK.

Comment on lines +1 to +111
1. **Create a snapshot** of the current state while `Commit` operations continue to
function with `store/v1`.
2. **Restore the snapshot** into the new StateStorage (SS) and StateCommitment (SC).
3. **Sync recent state changes** from `store/v1` to the new SS and SC.
4. After syncing, the `Commit` operation will be switched to the new `store/v2`.

Taking a snapshot is a lightweight operation. The snapshot is not stored on disk but
consumed by the `Restore` process, which replays state changes to the new SS and SC.

> **Note:** After migration, `store/v2` does **not** support historical queries.
If historical data access is required, a full state migration to `store/v2` is necessary.

## Usage

You can create a new `migration.Manager` by calling the following function:

```go
func NewManager(
db corestore.KVStoreWithBatch,
sm *snapshots.Manager,
ss *storage.StorageStore,
sc *commitment.CommitStore,
logger log.Logger
) *Manager
```

* `sc` (Commitment Store) can be `nil`. In that case, the Manager will migrate only
the state storage.
* The migration process is lazy, meaning data is migrated in the background while
`root.Store` remains fully operational.

To initiate the migration process, call the `Start` method:

```go
func (m *Manager) Start(ctx context.Context) error
```

> **Note:** It should be called by the RootStore, running in the background.

## Migration Flow

```mermaid
sequenceDiagram
autonumber

participant A as RootStore
participant B as MigrationManager
participant C as SnapshotsManager
participant D as StateCommitment
participant E as StateStorage

A->>B: Start
loop Old Data Migration
B->>C: Create Snapshot
C->>B: Stream Snapshot
B->>D: State Sync (Restore)
B->>E: Write Changeset (Restore)
end

loop New Commit Data Sync
A->>B: Commit(Changeset)
B->>B: Store Changeset
B->>D: Commit Changeset
B->>E: Write Changeset
end

B->>A: Switch to new store/v2
```

## Key Considerations

### Laziness and Background Operation

The migration is performed lazily, meaning it occurs in the background without
interrupting the current operations on root.Store. This allows the chain to continue
running while data is gradually migrated to `store/v2`. State synchronization ensures
that any new state changes during the migration are also applied to `store/v2`.

However, note that there may be a performance impact depending on the size of the data
being migrated, and it’s essential to monitor the migration process in production
environments.

### Handling Failures and Rollbacks

It is important to consider how the migration manager handles errors or system failures
during the migration process:

* If the migration fails, there is no impact on the existing `store/v1` operations,
but need to restart the migration process from the scratch.
* In the event of a critical failure after migration, a rollback may not be possible,
and it is needed to keep the `store/v1` backup for a certain period.

### Impact on Historical Queries

After the migration, the new `store/v2` does not support historical queries.
This limitation should be clearly understood before starting the migration process,
especially if the node relies on historical data for any operations.

If historical queries are required, users must fully migrate all historical data to `store/v2`.
Alternatively, keeping store/v1 accessible for historical queries could be an option.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Consider adding sections on testing and troubleshooting

The document provides comprehensive information about the migration process. To further enhance its usefulness, consider adding the following sections:

  1. Testing and Validation: Briefly describe any recommended steps for testing or validating the migration process after completion.
  2. Troubleshooting: Include a section on common issues that might arise during migration and how to resolve them.

These additions would provide a more complete guide for users undertaking the migration process.

🧰 Tools
🪛 Markdownlint

111-111: null
Files should end with a single newline character

(MD047, single-trailing-newline)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants