Conversation
| VerifyOnFetchMode::ReturnError => { | ||
| self.verify_block_integrity(&block).map_err(|error| { | ||
| anyhow::anyhow!( | ||
| "Celestia block integrity verification failed at height {height}: {error}" | ||
| ) | ||
| })?; | ||
| } |
There was a problem hiding this comment.
📝 Info: ReturnError mode double-wraps the error, losing the anyhow chain
At crates/adapters/celestia/src/da_service/mod.rs:380-384, the ReturnError branch calls .map_err(|error| anyhow::anyhow!("...{error}")) on the result of verify_block_integrity, which already returns anyhow::Result. This creates a new anyhow::Error using the Display of the inner error, discarding the original error's backtrace and cause chain. The user-visible error message is preserved (since {error} uses Display), but anyhow's .context() or direct ? propagation would retain the full chain. This is a minor style concern — not a functional bug — but could make debugging slightly harder in production when investigating verification failures.
Was this helpful? React with 👍 or 👎 to provide feedback.
Description
Re-adds the previously-reverted boolean block verification on fetch (PR #2489 / reverted in PR #2520). It is disabled by default to match current behaviour, but can be enabled via config.
Possible panic.
If it is enabled with log error, in some rare cases it can cause panic, which happens internally in the verifier; This will be addressed in follow up: #2404
CHANGELOG.mdwith a new entry if my PR makes any breaking changes or fixes a bug. If my PR removes a feature or changes its behavior, I provide help for users on how to migrate to the new behavior.Cargo.tomlchanges before opening the PRs. (Are all new dependencies necessary? Is any module dependency leaked into the full-node (hint: it shouldn't)?)Testing
All existing tests are passing
Docs
No updates