Fix/tx build should not change order of insertion with vector #262
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.
Description
On my attempt to fix bitcoindevkit/bdk#1794 in bitcoindevkit/bdk#1798, I broke the assumption that insertion order is preserved when
TxBuilder::ordering
isTxOrdering::Untouched
. Some users are relying in this assumption, so here I'm trying to restore it back, without adding a new dependency for this single use case like #252, or creating a new struct just to track this.In this fourth alternative solution I'm going back to use
Vec
to store the manually selected UTxOs.I was reluctant to do it in this way because
HashMap
seems a better solution giving its property of avoiding duplicates, but as we also want to keep the secuential nature of the insertion of UTxOs inTxBuilder
, here is an alternative aligned with that principle.May replace #252
May replace #261 .
Fixes #244
Notes to the reviewers
Also, as I was working on this, I came back to the following tests:
test_prexisting_foreign_utxo_have_no_precedence_over_local_utxo_with_same_outpoint
test_prexisting_local_utxo_have_precedence_over_foreign_utxo_with_same_outpoint
Motivated during the implementation and review of bitcoindevkit/bdk#1798.
Which required the underlying structure to also hold the properties of no duplication for manually selected UTxOs, as the structures were accessed directly for these cases.
The test tries to cover the case when there are two wallets using the same descriptor, one tracks transactions and the other does not. The first passes UTxOs belonging to the second one and this one creates transactions using the
add_foreign_utxo
interface.In this case it was expected for any
LocalUtxo
of the offline wallet to supersede any conflicting foreign UTxO. But, the simulation of this case went against the borrowing constraints of rust.By how costly was to reproduce this behavior for me in the tests, I would like to have second opinions in the feasibility of the test case.
Changelog notice
No public APIs are changed by these commits.
Checklists
Important
This pull request DOES NOT break the existing API
cargo +nightly fmt
andcargo clippy
before committing