[emma31-dev]

Description

Previously, UnlockUtxoCommand would attempt to unlock any outpoint passed by the user without checking whether it was actually a known wallet UTXO, which could cause silent no-ops or unexpected behaviour. This change adds a guard that checks each outpoint against the wallet's known UTXOs via get_utxo before calling unlock_outpoint just like LockUtxoCommand. if an outpoint is not recognised, a warning is printed to stderr and that entry is skipped, allowing the rest of the list to be processed normally.

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

[tvpeter]

The known behaviour when you test locking and unlocking UTXOs is that, when it locks and unlocks, it returns a json containing count and the items (UTXOs). So when you lock a UTXO, it returns the same output with count incremented and the locked UTXO in the items. Similar response is returned for unlocking a UTXO but this time, it decreases.

The same behaviour occurs when you supply a UTXO the wallet doesn't know about whether to lock or unlock. So there is no unexpected behaviour. You can read the entire conversation on the PR here #294.

Aside that, it will be more helpful to open an "Issue" whenever you think something is worth fixing/adding so others can share their perspective on the issue first before opening a PR.

Thank you.