docs: add documentation for bridge node pruning changes (WIP)#2402
docs: add documentation for bridge node pruning changes (WIP)#2402
Conversation
Add comprehensive documentation updates for upcoming bridge node changes: - Document new default pruning mode for bridge nodes (PR #4768) - Add --archival flag documentation for full historical data retention - Include routing exchange optimization notes (PR #4758) - Update hardware requirements to clarify pruned vs archival modes - Add migration guide for existing bridge node operators - Update custom networks docs with genesis hash requirements - Add breaking change warnings across all relevant pages Note: Version placeholders (TODO) added pending release of PR #4768 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Summary of ChangesHello @jcstein, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request updates the Celestia documentation to reflect significant changes in bridge node behavior, primarily the shift to default pruning mode and the introduction of an explicit archival mode. It provides crucial information for operators on how to manage their nodes, including a migration guide and specific considerations for private networks. The updates aim to clarify the new operational paradigms and ensure users can configure their bridge nodes appropriately for their specific needs, whether for reduced storage or full historical data access. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request provides comprehensive and much-needed documentation for the recent changes to bridge node pruning. The explanations of pruned vs. archival modes, the new --archival flag, and the migration guide are clear and well-structured. The changes are consistently applied across all relevant documentation files, which will be very helpful for users.
I've left a few minor suggestions to improve clarity and consistency in the configuration reference and custom networks documentation. Overall, this is an excellent documentation update.
|
|
||
| Starting from [TODO: Add version from PR #4768], bridge nodes support pruning configuration: | ||
|
|
||
| - `PruningWindow`: Defines how many blocks to keep (0 = keep all, default for non-archival nodes) |
There was a problem hiding this comment.
The description for PruningWindow is a bit confusing. The phrase (0 = keep all, default for non-archival nodes) could be misinterpreted as the default for pruned (non-archival) nodes is 0, which would mean they keep all data, contradicting the purpose of pruning. Please clarify this. For instance, you could specify the default pruning window for non-archival nodes and state that 0 is for disabling pruning.
| ``` | ||
|
|
||
| For archival bridge nodes, use the `--archival` flag when initializing and starting: | ||
| ```bash |
| ``` | ||
|
|
||
| 3. **Sync from a specific height or hash**: | ||
| ```bash |
|
🚀 Preview Deployment Your preview is ready: https://celestiaorg.github.io/docs-preview/pr-2402/ |
Overview
This PR adds comprehensive documentation for two important celestia-node changes:
--archivalflagThis PR contains placeholder TODOs that need to be updated once the release version is known. Search for
[TODO: Add version from PR #4768]to find all locations.Changes Made
Breaking Change Documentation
--archivalflag requirement for full historical dataNew Sections Added
Files Modified
app/operate/data-availability/bridge-node/page.mdx- Main documentation with all major changesapp/operate/data-availability/config-reference/page.mdx- New pruning configuration parametersapp/operate/data-availability/custom-networks/page.mdx- Genesis hash requirements for private networksapp/operate/getting-started/hardware-requirements/page.mdx- Storage specifications for pruned vs archivalapp/operate/networks/mainnet-beta/page.mdx- Network-specific notesapp/operate/networks/mocha-testnet/page.mdx- Network-specific notesapp/operate/networks/arabica-devnet/page.mdx- Network-specific notesapp/operate/networks/local-devnet/page.mdx- Docker example with--archivalflag📝 TODO Before Merging
Version Placeholders to Update
Once celestiaorg/celestia-node#4768 is included in a release, update these locations:
Bridge Node Page (
app/operate/data-availability/bridge-node/page.mdx):Config Reference (
app/operate/data-availability/config-reference/page.mdx):Custom Networks (
app/operate/data-availability/custom-networks/page.mdx):Hardware Requirements (
app/operate/getting-started/hardware-requirements/page.mdx):Network Pages:
Additional Updates Needed
[TODO: Add version from PR #4768]with the actual versionContext from Original PRs
PR #4768 - Pruning for Bridge Nodes
--archivalflag required for full historical dataPR #4758 - Routing Exchange
Addresses Concerns
This documentation specifically addresses the concern raised about private networks:
The docs now clearly explain that private network operators must either:
--archivalflag (simplest option)Review Checklist
cc @vgonkivs - for review once the version is finalized