fix(zetaclient): backport respect DisableTssBlockScan in Bitcoin observer #4598
fix(zetaclient): backport respect DisableTssBlockScan in Bitcoin observer #4598skosito wants to merge 1 commit into
Conversation
* fix(zetaclient): respect DisableTssBlockScan in Bitcoin observer * same fix in inbound tracker * log * changelog
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
original PR #4597
How Has This Been Tested?
Note
Medium Risk
Behavior changes to conditionally suppress Bitcoin inbound detection and voting; a mis-set
DisableTssBlockScancould cause missed deposits, though it is gated behind an explicit chain parameter flag.Overview
Respects
DisableTssBlockScanin the Bitcoin observer. When this chain parameter is enabled,ObserveInboundnow returns early and performs no block-range inbound scanning.Inbound tracker processing (
observeInboundTrackers) is also short-circuited under the same flag (with additional sampled logging), preventing votes on tracker-referenced deposits. Unit tests were added to ensure both paths return without attempting any Bitcoin RPC calls.Reviewed by Cursor Bugbot for commit 92a7597. Configure here.
Greptile Summary
This PR adds a
DisableTssBlockScanguard to the Bitcoin observer's inbound scanning path, mirroring the check that already exists in the EVM observer. Since Bitcoin has no smart-contract-based inbounds — all deposits go directly to the TSS address — the flag correctly short-circuits the entire inbound observation loop rather than just part of it.inbound.go: Early return afterupdateLastBlockwhenDisableTssBlockScanis set, so the chain-tip pointer stays fresh but block scanning stops.inbound_tracker.go: Same guard added toobserveInboundTrackers, preventing both external and internal tracker votes from being processed.inbound_test.go: Two focused unit tests verify the early-return paths without requiring any RPC mock setup for the scan operations.Confidence Score: 5/5
The change is a narrow, additive guard; it cannot break existing scan paths and has direct test coverage.
Both changed functions gain a clear early-return guarded by the existing chain parameter, with no mutation to downstream logic. The updateLastBlock call is preserved before the guard in ObserveInbound, keeping chain-tip tracking alive even when scanning is disabled, which is the correct trade-off for a clean resume once the flag is cleared. Tests confirm no RPC calls are made when the flag is set.
No files require special attention.
Important Files Changed
Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart TD A[ObserveInbound called] --> B[updateLastBlock] B --> C{DisableTssBlockScan?} C -- Yes --> D[log sampled info & return nil] C -- No --> E[GetScanRangeInboundSafe] E --> F[observeInboundInBlockRange SAFE] F --> G[SaveLastBlockScanned] G --> H[GetScanRangeInboundFast] H --> I[observeInboundInBlockRange FAST] I --> J[return nil] K[ProcessInboundTrackers / ProcessInternalTrackers] --> L[observeInboundTrackers] L --> M{DisableTssBlockScan?} M -- Yes --> N[log sampled info & return nil] M -- No --> O[truncate trackers at MaxInboundTrackersPerScan] O --> P[CheckReceiptAndPostVoteForBtcTxHash per tracker] P --> Q[return nil]Reviews (1): Last reviewed commit: "fix(zetaclient): respect DisableTssBlock..." | Re-trigger Greptile