-
Notifications
You must be signed in to change notification settings - Fork 431
Overhaul IPFS Troubleshooting guides with new content and structure #2046
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
base: main
Are you sure you want to change the base?
Conversation
remove pl-diagnose which isn't maintained and operated
🚀 Build Preview on IPFS ready
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR restructures and enriches the IPFS troubleshooting documentation by introducing high-level guides, adding new diagnostic tool references, and updating navigation.
- Adds a new “Helia Identify” section to the diagnostic tools reference
- Overhauls the main troubleshooting guide with broader retrieval/providing sections and integrates IPFS Check
- Splits out a dedicated “Troubleshooting Kubo” page and updates sidebars and redirects accordingly
Reviewed Changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.
Show a summary per file
File | Description |
---|---|
docs/reference/diagnostic-tools.md | Added “Helia Identify” browser‐based identify tool |
docs/how-to/troubleshooting.md | Expanded troubleshooting guide, integrated IPFS Check |
docs/how-to/troubleshooting-kubo.md | New dedicated Kubo troubleshooting instructions |
docs/.vuepress/redirects | Redirect updated from gateway-troubleshooting |
docs/.vuepress/config.js | Sidebar groups updated for troubleshooting guides |
docs/concepts/public-utilities.md | Added “IPFS Check” tool description |
docs/concepts/lifecycle.md | Updated providing step to mention reproviding |
Comments suppressed due to low confidence (1)
docs/how-to/troubleshooting.md:5
- [nitpick] There's an unfinished TODO block left in HTML comments—either remove it or flesh out the items so it's actionable.
<!-- ## TODO
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for gathering all this information in one place!
Some nits/suggestions inline
|
||
### Analyzing vars and memory statistics | ||
- **Change the reprovider strategy from `all` to either `pinned` or `roots`.** In both cases, only provider records for explicitly pinned content are advertised. Differences and tradeoffs are noted below: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: good place to push people towards newly added pinned+mfs
, and not just pinned
- **Change the reprovider strategy from `all` to either `pinned` or `roots`.** In both cases, only provider records for explicitly pinned content are advertised. Differences and tradeoffs are noted below: | |
- **Change the [Reprovider Strategy](https://github.com/ipfs/kubo/blob/master/docs/config.md#reproviderstrategy) from `all` to either `pinned+mfs` or `roots`.** In both cases, only provider records for explicitly pinned content are advertised. Differences and tradeoffs are noted below: |
|
||
### Analyzing vars and memory statistics | ||
- **Change the reprovider strategy from `all` to either `pinned` or `roots`.** In both cases, only provider records for explicitly pinned content are advertised. Differences and tradeoffs are noted below: | ||
- The `pinned` strategy will advertise both the root CIDs and child block CIDs (the entire DAG) of explicitly pinned content. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The `pinned` strategy will advertise both the root CIDs and child block CIDs (the entire DAG) of explicitly pinned content. | |
- The `pinned+mfs` strategy will advertise both the root CIDs and child block CIDs (the entire DAG) of explicitly pinned content and the locally available part of MFS. |
|
||
### Analyzing the CPU Profile | ||
2. Note the value for `LastReprovideDuration`. If it is close to 48 hours, select one of the following options, keeping in mind that each has tradeoffs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💭 depending on the strategy, the field right now will show how long a batch took, not the whole thing. I think its fine to keep the text here as-is – it will match reality once we have landed reprovide refactors in 0.36 and 0.37, however for now lets add this:
2. Note the value for `LastReprovideDuration`. If it is close to 48 hours, select one of the following options, keeping in mind that each has tradeoffs: | |
2. Note the value for `LastReprovideDuration`. If it is close to 48 hours, or if you notice a "reprovide taking too long" warning in your `ipfs daemon` output log, select one of the following options, keeping in mind that each has tradeoffs: |
|
||
 | ||
|
||
## Troubleshooting with Kubo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we have "### Troubleshooting providing with Kubo", maybe rename this to "### Troubleshooting retrieval with Kubo", and put it after "### Troubleshooting retrieval with IPFS Check" + add ipfs block get
as one extra step if providers are found?
Co-authored-by: Marcin Rataj <[email protected]>
What
Related to ipshipyard/roadmaps#13