Skip to content
This repository has been archived by the owner on Jun 11, 2022. It is now read-only.

Respect use case where multiple wallets and one is not on blockchain #59

Closed
HM999 opened this issue Nov 6, 2018 · 2 comments
Closed

Comments

@HM999
Copy link

HM999 commented Nov 6, 2018

Operation "transaction add-inputs" fails with "Wallet is not attached to any blockchain" with multiple wallets if wallet "previous" to wallet containing the UTxO is not attached to blockchain.

./target/debug/cardano-cli transaction add-input 3hrnAF 60540befd34211b88888dd216410ec8772d25645ad7826e69cb20662411e8a2a 1
Wallet is not attached to any blockchain

It is correct that UTxO inputs can come from different wallets, but should skip non-attached wallets.

Recreate: Make a wallet AAA, do not attach. Make a wallet BBB attach mainnet. Send coin to BBB. Create new transaction on mainnet, attempt to add-input from BBB. Will exit because it looks at AAA first, sees it is not attached and quits.

The function is load_attached_blockchain in /wallet/utils.rs which will process::exit if called with unattached wallet. Called by create_wallet_state_from_logs, which is called from multiple places. Where called for a wallet /wallet/commands.rs it is ok to exit I think because it is only called for one wallet. However, function is called from places in /transaction/commands.rs for ALL wallets, in this case should not exit, but move on to next wallet.

Eg. add-inputs, function find_input_in_all_utxos (probably same issue with sign() func, maybe others). So for add-inputs could fix in find_input_in_all_utxos with a continue maybe.

    for (_, wallet) in Wallets::load(root_dir.clone()).unwrap() {

        let blockchainname = wallet.config.attached_blockchain().unwrap();
        if !blockchainname.is_some() {
            // wallet is not attached to a blockchain
            continue;
        } 
@mzabaluev
Copy link
Contributor

I have started a branch to fix this.

Making create_wallet_state_from_logs non-panicky is less trivial than the type of changes done in #52, as it needs a unified error type for AddressLookup and all its impls.

@mzabaluev
Copy link
Contributor

File under #39

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants