Can't broadcast transactions with Asigna

[jfstn]

Describe the bug
Using the last @stacks/connect update, 8.1.8 that fixes Asigna connection by fixing the request call for that provider I'm unable to broadcast transactions.

To Reproduce

1. Go to Asigna Multisig;
2. Go to Apps;
3. Select Zest Protocol;
4. On the top right click on Connect Wallet;
5. Select Asigna provider;
6. Fund Asigna's wallet;
7. Attempt to supply STX;
8. Error is thrown while serializing values;

Expected behavior
Asigna should pop up and allow the user to confirm the transaction;

Screenshots

[diwakergupta]

@jfstn I went through the entire flow you described (Leather on Chrome on Mac) was was not able to repro:

• I created a fresh new vault on Asigna
• Apps -> Zest -> Supply
• Added STX successfully

I was watching the console throughput and didn't see any errors like the one in your screenshot.

If you can copy paste the entire stack trace from your JS console, that might help shed some more light.

[jfstn]

Hey @diwakergupta , this is the full stack trace 👇

I did use Xverse to connect to Asigna and I'm unable to connect to Asigna with Leather for some reason.

Can you try to connect to Asigna with Xverse and check if the issue is there?

[jfstn]

Was able to connect Asigna with Leather but it still fails.

There is a better stack trace here:

Where the issue happens:

I think it might be a conflict between expected clarity value representation, on the second image we can see that the serialisation is based on the type property.

The representations change with the latest @stacks/transactions major version 7, a comparison below 👇

[jfstn]

Seems like @stacks/connect has @stacks/transactions: 7.0.5 and @stacks/transactions: 6.17 as dependencies, maybe a bad serialisation import?

[janniks]

Analysis: Going through this with the debugger it fails on a generateUnsignedContractDeploy call, showing it's trying to do a deploy even though the user is triggering a contract call. The actual failure console throw is due to a serialization attempt of a contract deploy, but it's missing data it tries to serialize (resulting in the message in message.type being undefined.

Actual bug: I believe the bug is in the following Asigna tx building code:

// Iframe/index.tsx
case 'stx_signTransaction':
            const txPayload = data[method] as TransactionPayload; // faulty cast assuming data matches legacy Connect type

This should be using something like the MethodParams[method] for the cast, if any.

Here when we use this txPayload (aka data[method]), we are missing some properties.
This is passed into generateTx, which then misses the correct switch case (because the .txType || .payloadType don't exist on the object.
This causes the final else block to hit, which thinks the data should be used for a contract deploy.

---

CC @fess-v
Pinging Asigna on Discord. I'm also not sure why this would work on some wallets. I was able to reproduce exactly as reported with Xverse.

[fess-v]

Hey guys! shoud be fixed

[jfstn]

@fess-v can confirm it's working.

@janniks we should have some docs regarding Asigna as when using it the transactions are not broadcasted but rather just created to be later executed using Asigna's UI. I don't know how @stacks/connect handles this atm but we'll be implementing a special dialog just for Asigna on Zest.

[jfstn]

After some more investigation @stacks/connect seems to need some extra code to handle Asigna's special behaviour.

Creating transactions with Asigna errors atm, check the image below 👇🏽

That error eventually maps out to these lines here - https://github.com/hirosystems/connect/blob/main/packages/connect/src/request.ts#L372-L375 - which doesn't take into consideration what Asigna returns when request('stx_callContract') is called.

[janniks]

cc @fess-v what is the value (aka result) that Asigna returns here?

e.g. "67f65c299a17617679840507"

[fess-v]

Hey guys, we will remove that ID, which is our internal id returned at the moment. @janniks does undefined work fine in this case? just resolved promise, since we can't really return tx id without having all owners signed the transaction