forc call with `--wallet` parameter bugs

[zees-dev]

Description

forc call with --wallet parameter fails because the wallet has no base assets (0 balance), even for read-only function calls.

Steps to Reproduce

1. Deploy a minimal Sway contract
2. Run forc call without --wallet - works
3. Run forc call with --wallet - fails

Example Contract

contract;

abi Demo {
    fn get_count() -> u64;
}

impl Demo for Contract {
    fn get_count() -> u64 {
        5
    }
}

Commands

Working command (without wallet - uses default signer - which has funds..):

forc call --abi ./out/release/demo-abi.json $CONTRACT_ADDRESS get_count

Failing command (with wallet):

forc call --abi ./out/release/demo-abi.json $CONTRACT_ADDRESS get_count --wallet

Error Output

thread 'main' panicked at /Users/runner/work/sway/sway/forc-plugins/forc-client/src/op/call/missing_contracts.rs:32:10:
Failed to build transaction: Provider("failed to adjust inputs to cover for missing base asset: failed to get base asset (f8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07) inputs with amount: `1`: io error: Response errors; the target cannot be met due to insufficient coins available for f8f8b6283d7fa5b672b530cbb84fcccb4ff8dc40f8176ef4544ddb1f1952ad07. Collected: 0.")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behaviour

• The wallet parameter should not error/panic in the default dry-run mode - since funds are not required for read-only function calls.
• Error message update: The current error is cryptic. It should clearly state: "Wallet has insufficient funds. Please fund your wallet with base asset ()."
  • This is for simulation and/or live-mode - where user funds should be taken into account.

[jintukumardas]

Hi @zees-dev , could you assign this to me? I'd like to work on it.

[jintukumardas]

@zees-dev Thanks for assigning this to me. I've reproduced the issue locally and will begin investigating now.

[jintukumardas]

I dug into this further and it looks like in dry run mode we can bypass the user's --wallet flag entirely, and instead default to the built in signer that always has funds. Can you confirm if that's the right approach, or are we aiming for a change where balance is never validated for read calls? @zees-dev

[zees-dev]

Firstly, thanks for diving deep into this!

As for expected result, I think this would be the incorrect behaviour; if the --wallet is explicitly provided; the dry-run transaction should be executed under the context of the provided account* - which in this case is an explicit override (i.e. wallet provided with --wallet).
The whole point of the dry-run is to ensure confidence before the actual transaction is made; i.e. the user can validate changes before actually performing them.

[jintukumardas]

Firstly, thanks for diving deep into this!

As for expected result, I think this would be the incorrect behaviour; if the --wallet is explicitly provided; the dry-run transaction should be executed under the context of the provided account* - which in this case is an explicit override (i.e. wallet provided with --wallet). The whole point of the dry-run is to ensure confidence before the actual transaction is made; i.e. the user can validate changes before actually performing them.

The problem is the transaction builder keeps adding inputs for gas even when using StateReadOnly. I tried other ways to skip this, but I get error like:

Error: provider: failed to adjust inputs to cover for missing base asset: failed to get base asset (...) inputs with amount: 1

This looks like a limitation of the current architecture where transaction building always validates and adds inputs for gas fees, even for read-only dry-run operations.

Should we add small amount of the base asset to the wallet for a dry-run? Another fix would require changes to support building transactions without inputs for dry-run scenarios.

[jintukumardas]

I spent more time on it but it didn't help. The only thing that works is either adding funds or, if the balance is 0, using the default signer.

[zees-dev]

Adding the base asset I believe won't work since this won't reflect the state of the address/account on the target node.

It maybe worth diving into the inputs used by the default signer (and how these are derived).
Also you could test by running local node with state config configured with the wallet having funds - in fact we introduced account funding as part of #7378

Sorry these are the only pointers I can think of (from top of my head) without diving deeper into the actual issue

[jintukumardas]

I gave it some more thought, and the most practical solution I've come up with for now is this:

In dry-run mode, we first try to build the transaction using the provided wallet. If that fails because of not enough funds, we use a default signer to build the transaction instead, but still execute the dry-run with the provided wallet's context. This way the user can validate changes before actually performing them.

This seems to be working well (attached screenshot below). Let me know if this works.

[jintukumardas]

Hi @zees-dev , could you confirm if the solution looks good, or would you like me to think alternatives?