Download missing subtree files before block revalidation

[freemans13]

Problem

When revalidating old invalid blocks via the RevalidateBlock RPC endpoint, the pruner may have already removed the subtree files (FileTypeSubtreeToCheck and FileTypeSubtreeData). This causes revalidation to fail because the validation logic cannot access the required data.

Solution

Call fetchSubtreeDataForBlock() at the start of RevalidateBlock() to download any missing subtree files before proceeding with validation. This method:

• Checks if each subtree file exists locally
• Downloads missing files from the original peer's DataHubURL
• Falls back to alternative peers via GetPeersAtMaxHeight() if the primary peer fails

The fetch is only attempted when p2pClient is available, since peer communication is required to download the files.

Changes

• services/blockvalidation/Server.go: Added subtree fetch logic in RevalidateBlock() before calling ValidateBlockWithOptions()

Testing

• Build verified: go build ./services/blockvalidation/...
• Manual testing: Create an invalid block, let pruner remove subtrees, call RevalidateBlock via gRPC

🤖 Generated with Claude Code

[github-actions]

🤖 Claude Code Review

Status: Complete

Current Review:

The PR adds subtree data fetching before block revalidation, which correctly addresses the pruning issue. However, there is one existing concern:

• Empty baseURL handling (inline comment): When GetPeer() fails at Server.go:1168, an empty baseURL is passed to fetchSubtreeDataForBlock(), causing invalid URLs like /subtree/hash. While fallback logic exists, this creates unnecessary HTTP failures and warning logs. Consider early validation or explicit error handling.

The core logic is sound and the PR description accurately explains the problem and solution.

[github-actions]

The error from GetPeer is silently ignored. If GetPeer fails, baseURL will be empty, causing fetchSubtreeDataForBlock to construct an invalid URL. While there is fallback logic, this causes unnecessary HTTP failures and warning logs. Consider logging the GetPeer error or handling it explicitly, similar to catchup_get_block_headers.go:438

[freemans13]

Fixed

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud