Contract invocation arguments should accept BytesN<32> for contract hashes

[kalepail]

They used to, they don't anymore, despite what the help text says to the contrary.

% soroban contract invoke --id 17bd...232f --source Default --network Futurenet -- new_liqpool -h

Usage: new_liqpool [OPTIONS]

Options:
      --salt <32_hex_bytes>  Example:
                               --salt efefefefefefefefefefefefefefefefefefefefefefefefefefefefefefefef
      --token_b <Address>    Can be public key (G13..), a contract hash (6c45307) or an identity (alice), 
                             Example:
                               --token_b GDIY6AQQ75WMD4W46EYB7O6UYMHOCGQHLAQGQTKHDX4J2DYQCHVCR4W4
      --token_a <Address>    Can be public key (G13..), a contract hash (6c45307) or an identity (alice), 
                             Example:
                               --token_a GDIY6AQQ75WMD4W46EYB7O6UYMHOCGQHLAQGQTKHDX4J2DYQCHVCR4W4
  -h, --help                 Print help (see more with '--help')
% soroban contract invoke --id 17bd...232f --source Default --network Futurenet -- new_liqpool --salt deadbeef --token_a 17c0...357e8 --token_b dab0...772b

error: parsing argument token_a: value is not parseable to Some(
    Address,
)

[paulbellamy]

Recent, bug, but part of #403

[sreuland]

the workaround for now is to convert BytesN<32> to strkey contract encoding correct? assuming using one of sdk's which have this support such as the soroban js lib with StrKey.encodeContract().

[kalepail]

Correct that is the workaround.
I've also built https://rpciege.com/convert/<hex-or-strkey> as a stop gap.

[paulbellamy]

CLI should actually NOT accept 32-byte hexes for an Address type. 32-bytes is not enough to tell if an address is for a user account or a contract. As mentioned above, the correct fix is to use a C or G strkey, which encodes that data with the key.

[kalepail]

I feel like it's safe to assume as far as backwards compatibility is concerned if it's a BytesN<32> it's a contract. No one is passing public keys as hexes as the G... paradigm is already well established