Conversation
📝 WalkthroughWalkthroughLarge-scale documentation restructuring: consolidated Bootstrap into Configuration, moved logging docs to Operations, removed Extras, added UTxO RPC, Ouroboros, and Tx3 integration docs, and updated metadata ordering across multiple documentation directories. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~35 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/content/configuration/introduction.mdx (1)
12-12:⚠️ Potential issue | 🟡 MinorMinor grammatical fix: "name" → "named".
📝 Suggested fix
-- Config file name `dolos.toml` in the folder of execution. +- Config file named `dolos.toml` in the folder of execution.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/configuration/introduction.mdx` at line 12, Update the sentence "Config file name `dolos.toml` in the folder of execution." to use "named" instead of "name" so it reads "Config file named `dolos.toml` in the folder of execution." — locate the exact string in the introduction content (the markdown line containing `dolos.toml`) and replace "name" with "named" to correct the grammar.
🧹 Nitpick comments (1)
docs/content/bootstrap/local.mdx (1)
48-60: Consider clarifying thatrelaysubcommand works for both local and public nodes.The documentation uses
dolos bootstrap relayfor the "Local Node" scenario, which is the same command shown inrelay.mdxfor "Public Relay". While technically correct (the relay subcommand works for any peer), a brief note explaining this could help users understand they're using the same underlying bootstrap method with different peer configurations.📝 Suggested clarification
## Execution -To initialize the data stores for syncing from origin, run: +To initialize the data stores for syncing from origin, use the `relay` bootstrap method (which works for both local and public peers):🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/bootstrap/local.mdx` around lines 48 - 60, Add a short clarifying note after the "dolos bootstrap relay" command explaining that the "relay" subcommand is the same bootstrap mechanism used for both local and public peers (it works for any peer configuration), and link or reference the relay documentation (relay.mdx) for differences in peer configuration; update the paragraph containing "dolos bootstrap relay" and optionally the following "dolos daemon" line to include one sentence like "Note: the `dolos bootstrap relay` command is the same for local and public nodes — see relay.mdx for configuring peers."
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/content/installation/docker.mdx`:
- Around line 34-39: The example image tag "ghcr.io/txpipe/dolos:v1" is a
floating major alias, not a fixed production pin; update the example to show a
fully pinned release (e.g. use a specific semver like
"ghcr.io/txpipe/dolos:v1.2.3") or add a brief sentence after the example
clarifying that "v1" is a moving major tag and recommending using an exact
release tag (major.minor.patch) for production deployments; locate the example
string "ghcr.io/txpipe/dolos:v1" in the docs and replace or augment it
accordingly.
In `@docs/content/integrations/blaze.mdx`:
- Line 10: Replace the inconsistent expansion "UTxORPC" with the standardized
"UTxO RPC" wherever it expands the shorthand "U5C" in this document;
specifically change the phrase that reads "U5C (short for UTxORPC)" to "U5C
(short for UTxO RPC)" so it matches the link label "[UTxO RPC documentation]"
and the renamed API page.
In `@docs/content/integrations/tx3.mdx`:
- Around line 21-26: Update the docs to explicitly state that permissive_cors
defaults to true in the configuration (i.e., omitted values are treated as true
in the config default), and add a brief security callout advising operators to
set permissive_cors to false in production; reference the configuration option
name permissive_cors and the config default behavior in your wording so readers
understand the actual server default and the recommended mitigation.
In `@docs/content/operations/modes.mdx`:
- Around line 41-45: The table uses the term "relay" in the "daemon" row without
defining it; update the docs by either adding a short definition of "relay"
above the table (e.g., "relay: forwards data/requests between peers or
networks") or revise the "daemon" row to avoid an undefined term (e.g., "daemon
| sync + serve (includes relay functionality)"). Refer to the table entries
"daemon", "sync", "serve", and the undefined term "relay" when making the change
so readers immediately understand whether relay is a standalone mode or part of
daemon.
In `@docs/content/what.mdx`:
- Around line 15-18: Replace the incorrect description of TRP in the API
overview: instead of saying "TRP enables real-time streaming of chain events,"
update the clause to state that TRP is the Transaction Resolver Protocol used by
Tx3 clients to resolve and submit transactions (and optionally link integrators
to the Tx3 client interface), and keep the real-time streaming reference pointed
at the actual streaming interface (if intended) such as the streaming
API/real-time endpoint; modify the sentence in the paragraph containing "TRP"
and "Tx3" accordingly so the overview accurately directs integrators to TRP for
transaction resolution/submission.
- Around line 41-45: Update the wording under the "## Simple bootstrapping"
section: replace the phrase "full mainnet node" (the sentence about Mithril
bootstrapping syncing a full mainnet node) with language that calls it a
"mainnet Dolos node/instance" or "mainnet Dolos deployment" and add that Dolos
is a lightweight Cardano data node that keeps an updated ledger copy without
performing full consensus validation, relying on trusted upstream peers; edit
the sentence mentioning Mithril snapshot import (and the following sentence
about snapshots) to reflect this rephrasing so the architecture story remains
consistent.
---
Outside diff comments:
In `@docs/content/configuration/introduction.mdx`:
- Line 12: Update the sentence "Config file name `dolos.toml` in the folder of
execution." to use "named" instead of "name" so it reads "Config file named
`dolos.toml` in the folder of execution." — locate the exact string in the
introduction content (the markdown line containing `dolos.toml`) and replace
"name" with "named" to correct the grammar.
---
Nitpick comments:
In `@docs/content/bootstrap/local.mdx`:
- Around line 48-60: Add a short clarifying note after the "dolos bootstrap
relay" command explaining that the "relay" subcommand is the same bootstrap
mechanism used for both local and public peers (it works for any peer
configuration), and link or reference the relay documentation (relay.mdx) for
differences in peer configuration; update the paragraph containing "dolos
bootstrap relay" and optionally the following "dolos daemon" line to include one
sentence like "Note: the `dolos bootstrap relay` command is the same for local
and public nodes — see relay.mdx for configuring peers."
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 78ddf601-eecd-4313-979e-48fa12946471
📒 Files selected for processing (30)
docs/content/apis/_meta.ymldocs/content/apis/grpc.mdxdocs/content/apis/minibf.mdxdocs/content/apis/ouroboros.mdxdocs/content/bootstrap/_meta.ymldocs/content/bootstrap/index.mdxdocs/content/bootstrap/local.mdxdocs/content/bootstrap/mithril.mdxdocs/content/bootstrap/relay.mdxdocs/content/configuration/_meta.ymldocs/content/configuration/index.mdxdocs/content/configuration/initialize.mdxdocs/content/configuration/introduction.mdxdocs/content/configuration/schema.mdxdocs/content/extras/Rationale.mdxdocs/content/extras/_meta.ymldocs/content/index.mdxdocs/content/installation/_meta.ymldocs/content/installation/binaries.mdxdocs/content/installation/docker.mdxdocs/content/integrations/_meta.ymldocs/content/integrations/blaze.mdxdocs/content/integrations/tx3.mdxdocs/content/operations/_meta.ymldocs/content/operations/logging.mdxdocs/content/operations/modes.mdxdocs/content/operations/tracing.mdxdocs/content/running/_meta.ymldocs/content/running/logging.mdxdocs/content/what.mdx
💤 Files with no reviewable changes (5)
- docs/content/running/logging.mdx
- docs/content/running/_meta.yml
- docs/content/configuration/initialize.mdx
- docs/content/extras/Rationale.mdx
- docs/content/extras/_meta.yml
Comment on lines
+21
to
+26
| | Property | Type | Description | | ||
| |---------------------|---------|----------------------------------------------------------| | ||
| | listen_address | string | Local address (`IP:PORT`) to listen for TRP connections | | ||
| | max_optimize_rounds | integer | Max optimization rounds for fee balancing (default: 10) | | ||
| | permissive_cors | boolean | Allow cross-origin requests from any origin | | ||
| | extra_fees | integer | Optional extra lovelace to add during fee optimization | |
There was a problem hiding this comment.
Call out the default-open CORS behavior.
permissive_cors is security-sensitive, but Lines 21-26 only describe what it does. The implementation defaults omitted values to true (crates/core/src/config.rs:779-823), so please state that explicitly here; otherwise the example reads more locked down than the server actually is.
📝 Suggested doc fix
-| permissive_cors | boolean | Allow cross-origin requests from any origin |
+| permissive_cors | boolean | Allow cross-origin requests from any origin (default: true) |📝 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.
Suggested change
| | Property | Type | Description | | |
| |---------------------|---------|----------------------------------------------------------| | |
| | listen_address | string | Local address (`IP:PORT`) to listen for TRP connections | | |
| | max_optimize_rounds | integer | Max optimization rounds for fee balancing (default: 10) | | |
| | permissive_cors | boolean | Allow cross-origin requests from any origin | | |
| | extra_fees | integer | Optional extra lovelace to add during fee optimization | | |
| | Property | Type | Description | | |
| |---------------------|---------|----------------------------------------------------------| | |
| | listen_address | string | Local address (`IP:PORT`) to listen for TRP connections | | |
| | max_optimize_rounds | integer | Max optimization rounds for fee balancing (default: 10) | | |
| | permissive_cors | boolean | Allow cross-origin requests from any origin (default: true) | | |
| | extra_fees | integer | Optional extra lovelace to add during fee optimization | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/content/integrations/tx3.mdx` around lines 21 - 26, Update the docs to
explicitly state that permissive_cors defaults to true in the configuration
(i.e., omitted values are treated as true in the config default), and add a
brief security callout advising operators to set permissive_cors to false in
production; reference the configuration option name permissive_cors and the
config default behavior in your wording so readers understand the actual server
default and the recommended mitigation.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
docs/content/what.mdx (1)
23-25: Minor: Consider hyphenating "Conway-era".The static analysis tool suggests "Conway-era support" with a hyphen for compound adjective style. This is a minor stylistic improvement.
📝 Optional style improvement
-With Conway era support, Dolos also tracks governance data including delegation representatives (DReps) and proposals. +With Conway-era support, Dolos also tracks governance data including delegation representatives (DReps) and proposals.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/what.mdx` around lines 23 - 25, Update the phrase "Conway era support" to use the compound-adjective hyphenation "Conway-era support" in the text block titled "Comprehensive Cardano support" (replace the occurrence of the substring "Conway era support" with "Conway-era support") so the compound adjective is styled correctly.docs/content/integrations/tx3.mdx (1)
21-27: Add a security note forpermissive_corsin production.The default value is now documented (addressing the prior feedback), but operators should be warned that
permissive_cors: trueallows any origin and is unsuitable for production deployments exposed to the internet.📝 Suggested addition after the table
| extra_fees | integer | Optional extra lovelace to add during fee optimization | + +:::caution +The `permissive_cors` option defaults to `true`, which allows cross-origin requests from any domain. For production deployments, set `permissive_cors = false` or configure appropriate CORS policies at your reverse proxy. +:::🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/integrations/tx3.mdx` around lines 21 - 27, Add a concise security note immediately after the properties table warning that permissive_cors: true allows any origin and is unsafe for public production deployments; recommend setting permissive_cors to false for internet-exposed deployments, mention the risk of unwanted cross-origin access and credential exposure, and suggest operators explicitly configure allowed origins or use a proxy/CORS whitelist instead of relying on the default.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/content/integrations/tx3.mdx`:
- Around line 54-60: The Aside in docs/content/integrations/tx3.mdx incorrectly
implies Dolos has a default TRP port; update the text to clarify that while the
Tx3 CLI's built-in cardano-local network defaults to http://localhost:8164,
Dolos' TRP configuration (see TrpConfig and its required listen_address field)
has no default and must be explicitly set in Dolos' config or it will fail to
start; revise the example note and the invocation suggestion to state this
requirement and recommend setting listen_address in Dolos' config when using the
local profile.
- Around line 76-88: The Rust example uses non-existent APIs (Tx3Client,
CardanoSigner::from_mnemonic, Party::signer, Party::address, tx(), with_party())
and will not compile; replace this snippet with a correct example using the
actual crate (e.g., tx3_sdk::trp::Client and its real methods) or remove the
example and point readers to the official Tx3 docs; locate the block that
constructs Tx3Client and calls .with_party / .tx and either rewrite it to use
tx3_sdk::trp::Client and the SDK's actual authentication/signing flow or delete
it and add a link to https://docs.txpipe.io/tx3 for the supported usage.
---
Nitpick comments:
In `@docs/content/integrations/tx3.mdx`:
- Around line 21-27: Add a concise security note immediately after the
properties table warning that permissive_cors: true allows any origin and is
unsafe for public production deployments; recommend setting permissive_cors to
false for internet-exposed deployments, mention the risk of unwanted
cross-origin access and credential exposure, and suggest operators explicitly
configure allowed origins or use a proxy/CORS whitelist instead of relying on
the default.
In `@docs/content/what.mdx`:
- Around line 23-25: Update the phrase "Conway era support" to use the
compound-adjective hyphenation "Conway-era support" in the text block titled
"Comprehensive Cardano support" (replace the occurrence of the substring "Conway
era support" with "Conway-era support") so the compound adjective is styled
correctly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4cd3665b-9424-495f-a3e6-f3949125e629
📒 Files selected for processing (6)
docs/content/configuration/introduction.mdxdocs/content/installation/docker.mdxdocs/content/integrations/blaze.mdxdocs/content/integrations/tx3.mdxdocs/content/operations/modes.mdxdocs/content/what.mdx
🚧 Files skipped from review as they are similar to previous changes (4)
- docs/content/operations/modes.mdx
- docs/content/integrations/blaze.mdx
- docs/content/installation/docker.mdx
- docs/content/configuration/introduction.mdx
Comment on lines
+54
to
+60
| <Aside type="note"> | ||
| The built-in `cardano-local` network already defaults to `http://localhost:8164`, matching the default Dolos TRP port. If you're running Dolos locally with default settings, you can use the `local` profile directly: | ||
|
|
||
| ```bash | ||
| trix invoke --profile local | ||
| ``` | ||
| </Aside> |
There was a problem hiding this comment.
Clarify that Dolos has no default TRP port.
The aside states this matches "the default Dolos TRP port," but according to TrpConfig in crates/core/src/config.rs, listen_address is a required field with no default. Dolos will fail to start TRP if the address is omitted.
The Tx3 CLI's cardano-local network may default to port 8164, but Dolos itself requires explicit configuration.
📝 Suggested rewording
<Aside type="note">
-The built-in `cardano-local` network already defaults to `http://localhost:8164`, matching the default Dolos TRP port. If you're running Dolos locally with default settings, you can use the `local` profile directly:
+The built-in `cardano-local` network already defaults to `http://localhost:8164`. If you configure Dolos with `listen_address = "[::]:8164"` as shown above, you can use the `local` profile directly:📝 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.
Suggested change
| <Aside type="note"> | |
| The built-in `cardano-local` network already defaults to `http://localhost:8164`, matching the default Dolos TRP port. If you're running Dolos locally with default settings, you can use the `local` profile directly: | |
| ```bash | |
| trix invoke --profile local | |
| ``` | |
| </Aside> | |
| <Aside type="note"> | |
| The built-in `cardano-local` network already defaults to `http://localhost:8164`. If you configure Dolos with `listen_address = "[::]:8164"` as shown above, you can use the `local` profile directly: | |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/content/integrations/tx3.mdx` around lines 54 - 60, The Aside in
docs/content/integrations/tx3.mdx incorrectly implies Dolos has a default TRP
port; update the text to clarify that while the Tx3 CLI's built-in cardano-local
network defaults to http://localhost:8164, Dolos' TRP configuration (see
TrpConfig and its required listen_address field) has no default and must be
explicitly set in Dolos' config or it will fail to start; revise the example
note and the invocation suggestion to state this requirement and recommend
setting listen_address in Dolos' config when using the local profile.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Documentation
Chores