test(key-wallet): cover the change-address guard - #920
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughChangesFunding change address
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change preserves configured change addresses during transaction funding. No concrete merge-blocking risk is identified in the supplied context. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
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 `@key-wallet/src/wallet/managed_wallet_info/transaction_builder.rs`:
- Around line 127-129: Update TransactionBuilder::set_funding so it does not
call next_change_address or advance the change pool when initializing
change_addr; defer derivation until the build path has the final address, or
otherwise ensure set_change_address explicitly prevents and replaces any derived
address. Preserve the existing behavior for callers that do not provide a change
address, and add regression coverage for
set_funding(...).set_change_address(...).build_unsigned().
- Around line 127-129: Validate explicit change addresses in set_funding by
comparing the address network with funds_acc.network()/acc.network before
preserving change_addr, and return a new BuilderError variant on mismatch. Keep
matching explicit addresses unchanged, update
set_funding_keeps_an_explicit_change_address to use a matching-network
fixture/address, and add a regression test covering rejection of a cross-network
address.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 16ccc41c-dfd2-40f9-a50f-b927f63181a9
📒 Files selected for processing (1)
key-wallet/src/wallet/managed_wallet_info/transaction_builder.rs
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #920 +/- ##
==========================================
+ Coverage 77.27% 77.30% +0.03%
==========================================
Files 329 329
Lines 83624 83642 +18
==========================================
+ Hits 64617 64662 +45
+ Misses 19007 18980 -27
|
|
This PR has merge conflicts with the base branch. Please rebase or merge the base branch into your branch to resolve them. |
`fund_from` only asks the funding account for a change address when the builder has none, so a caller's `set_change_address` survives `add_funding`. Nothing tested that. The guard reads as a redundant `is_none` check next to an unconditional assignment, and removing it would compile, pass every test, and silently override the caller's address — while also advancing the change pool to derive one that is then discarded. The test asserts both halves: the explicit address is still there afterwards, and the account hands out the same next change address a pristine one would. Removing the guard fails it on the first assertion. The doc on `add_funding` now says the same thing in words, since the behaviour is a contract of the funding call rather than an implementation detail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SbgCpMiBjnpvW4CyEEsKXw
9c89c68 to
ef0cbe9
Compare
e44064e to
8262e04
Compare
This started as a fix:
set_fundingderived a change address unconditionally, discarding one the caller had set and burning a pool address to do it. #925 rewrote that path intoadd_funding/fund_fromfour days later and carried the guard with it, so the fix has been indevsince 7 August — which is why there is no production change left here.What #925 did not bring was a test. The guard reads as a redundant
is_nonenext to an unconditional assignment, and every existing test funds first and sets the address after, an order that never reaches it. Removing it would compile, pass the suite, and silently override the caller's address while advancing the change pool for one that is thendiscarded.
Folded into
set_funding_skips_reserved_utxos, whose fixture already had what it needed, plus a note onadd_fundingstating the ordering contract. Verified by removing the guard: the new assertion fails.Two findings from the earlier review are deliberately not addressed; reasoning in the thread.
Summary by CodeRabbit
Bug Fixes
Documentation
Tests