feat: add fast sync pivot support to mainnet and testnet start scripts#276
Open
wgr523 wants to merge 2 commits into
Open
feat: add fast sync pivot support to mainnet and testnet start scripts#276wgr523 wants to merge 2 commits into
wgr523 wants to merge 2 commits into
Conversation
📝 WalkthroughWalkthroughThis PR adds environment-driven configuration to both mainnet and testnet node startup scripts. Each script now supports SYNC_MODE to override the default sync mode and FASTSYNC_PIVOT environment variables to configure fast-sync pivot parameters, with validation requiring all three pivot variables together before building and appending the corresponding XDC command-line arguments. ChangesNode Startup Configuration
🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers:
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
benjamin202410
approved these changes
May 29, 2026
![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
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@mainnet/get_pivot_for_fast_sync.sh`:
- Around line 11-18: The RPC curl calls (creating epoch_response, block_response
and block_details for methods XDPoS_getMasternodesByNumber,
XDPoS_getBlockInfoByEpochNum and eth_getBlockByHash) lack fail-fast flags and
timeouts and the block_details response is missing the jq .error guard; update
each curl invocation to include --fail and sensible timeouts (e.g.,
--connect-timeout and --max-time) and optional retry flags, and after fetching
block_details add the same jq error check used for epoch_response/block_response
(test .error and exit on failure) before accessing .result.stateRoot so
transport/http failures don’t produce confusing jq parse errors.
In `@mainnet/README.md`:
- Around line 46-50: The README currently suggests using `bash
get_pivot_for_fast_sync.sh >> .env`, which can append duplicate FASTSYNC_PIVOT_*
entries; update the instructions to instead write the script output to a
temporary file and replace or update existing FASTSYNC_PIVOT_* keys in `.env`
(or overwrite `.env` safely), e.g., run `get_pivot_for_fast_sync.sh` to a temp
file and then copy/merge its FASTSYNC_PIVOT_* values into `.env` replacing any
existing keys; reference the script name `get_pivot_for_fast_sync.sh` and the
`FASTSYNC_PIVOT_*` env keys so readers know which values must be replaced rather
than blindly appended.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8f12e204-7943-469a-9f46-37e6a0c502bb
📒 Files selected for processing (4)
mainnet/README.mdmainnet/get_pivot_for_fast_sync.shtestnet/README.mdtestnet/get_pivot_for_fast_sync.sh
✅ Files skipped from review due to trivial changes (1)
- testnet/README.md
Comment on lines
+11
to
+18
| epoch_response=$(curl -s -X POST "$RPC_URL" \ | ||
| -H "Content-Type: application/json" \ | ||
| -d '{ | ||
| "jsonrpc": "2.0", | ||
| "method": "XDPoS_getMasternodesByNumber", | ||
| "params": ["latest"], | ||
| "id": 1 | ||
| }') |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify helper scripts currently use bare `curl -s` without timeout/fail flags.
rg -n --type=sh -C2 '\bcurl\s+-s\b' mainnet/get_pivot_for_fast_sync.sh testnet/get_pivot_for_fast_sync.shRepository: XinFinOrg/XinFin-Node
Length of output: 2120
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n --type=sh '\bcurl\b' mainnet/get_pivot_for_fast_sync.sh
echo "----"
rg -n --type=sh '\bcurl\s+-s\b' mainnet/get_pivot_for_fast_sync.shRepository: XinFinOrg/XinFin-Node
Length of output: 372
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show only the relevant call sites with line numbers
sed -n '1,120p' mainnet/get_pivot_for_fast_sync.sh | nl -ba | sed -n '1,120p'
echo "----"
nl -ba mainnet/get_pivot_for_fast_sync.sh | sed -n '1,110p' | sed -n '8,30p'
echo "----"
nl -ba mainnet/get_pivot_for_fast_sync.sh | sed -n '45,65p'
echo "----"
nl -ba mainnet/get_pivot_for_fast_sync.sh | sed -n '65,90p'Repository: XinFinOrg/XinFin-Node
Length of output: 108
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- mainnet/get_pivot_for_fast_sync.sh (top area) ----"
cat -n mainnet/get_pivot_for_fast_sync.sh | sed -n '1,140p' | sed -n '1,90p'
echo "---- mainnet/get_pivot_for_fast_sync.sh (lines 40-90) ----"
cat -n mainnet/get_pivot_for_fast_sync.sh | sed -n '40,90p'Repository: XinFinOrg/XinFin-Node
Length of output: 5534
Add fail-fast + timeout controls to all RPC curl calls.
All three JSON-RPC requests (XDPoS_getMasternodesByNumber, XDPoS_getBlockInfoByEpochNum, eth_getBlockByHash) use curl -s without --fail and without timeouts/retries, so HTTP/transport failures can hang and/or surface later as confusing jq parse issues. Also, .error is checked only for the first two responses; the eth_getBlockByHash response doesn’t have the same guard.
Suggested hardening
+curl_opts=(--silent --show-error --fail --connect-timeout 5 --max-time 20 --retry 3 --retry-delay 1)
-epoch_response=$(curl -s -X POST "$RPC_URL" \
+epoch_response=$(curl "${curl_opts[@]}" -X POST "$RPC_URL" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "XDPoS_getMasternodesByNumber",
"params": ["latest"],
"id": 1
}')
-block_info_response=$(curl -s -X POST "$RPC_URL" \
+block_info_response=$(curl "${curl_opts[@]}" -X POST "$RPC_URL" \
-H "Content-Type: application/json" \
-d "{
\"jsonrpc\": \"2.0\",
\"method\": \"XDPoS_getBlockInfoByEpochNum\",
\"params\": [$current_epoch],
\"id\": 1
}")
-block_details=$(curl -s -X POST "$RPC_URL" \
+block_details=$(curl "${curl_opts[@]}" -X POST "$RPC_URL" \
-H "Content-Type: application/json" \
-d "{
\"jsonrpc\": \"2.0\",
\"method\": \"eth_getBlockByHash\",
\"params\": [\"$block_hash\", false],
\"id\": 1
}")Add the same jq .error check pattern for block_details before reading .result.stateRoot.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@mainnet/get_pivot_for_fast_sync.sh` around lines 11 - 18, The RPC curl calls
(creating epoch_response, block_response and block_details for methods
XDPoS_getMasternodesByNumber, XDPoS_getBlockInfoByEpochNum and
eth_getBlockByHash) lack fail-fast flags and timeouts and the block_details
response is missing the jq .error guard; update each curl invocation to include
--fail and sensible timeouts (e.g., --connect-timeout and --max-time) and
optional retry flags, and after fetching block_details add the same jq error
check used for epoch_response/block_response (test .error and exit on failure)
before accessing .result.stateRoot so transport/http failures don’t produce
confusing jq parse errors.
Comment on lines
+46
to
+50
| > Run `bash get_pivot_for_fast_sync.sh` to extract a fresh pivot (block number, hash, and state root) from a public XinFin RPC node. The script prints the values in `.env` format, so you can append the output directly: | ||
| > | ||
| > ```bash | ||
| > bash get_pivot_for_fast_sync.sh >> .env | ||
| > ``` |
There was a problem hiding this comment.
Avoid repeatedly appending duplicate pivot keys to .env.
Using >> .env every time can accumulate conflicting FASTSYNC_PIVOT_* values. Recommend documenting a replace/edit flow (or overwrite to a temp file, then copy values) instead of repeated append.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@mainnet/README.md` around lines 46 - 50, The README currently suggests using
`bash get_pivot_for_fast_sync.sh >> .env`, which can append duplicate
FASTSYNC_PIVOT_* entries; update the instructions to instead write the script
output to a temporary file and replace or update existing FASTSYNC_PIVOT_* keys
in `.env` (or overwrite `.env` safely), e.g., run `get_pivot_for_fast_sync.sh`
to a temp file and then copy/merge its FASTSYNC_PIVOT_* values into `.env`
replacing any existing keys; reference the script name
`get_pivot_for_fast_sync.sh` and the `FASTSYNC_PIVOT_*` env keys so readers know
which values must be replaced rather than blindly appended.
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
2 participants
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
New Features
Documentation