Sending transaction after signing with Maiar wallet fails on some devices

[Alannek1992]

Hi Julian,

This problem seems to be very difficult to replicate. But in general I am using your template and it works perfectly fine for me.

Recently I got a lot of reports that the sending transaction fails after signin with maiiar wallet. They have the same problem on your template website -> https://elrond-nextjs-dapp.netlify.app/.

So Far I managed to find that the line which is failing is await apiNetworkProvider.sendTransaction(tx); within sendTxOperation.ts.

This is then very general exception: Error: Request error on url [transactions]: [{"statusCode":400,"message":""}] at ApiNetworkProvider.handleApiError (apiNetworkProvider.js?5989:213:1) at ApiNetworkProvider.eval (apiNetworkProvider.js?5989:202:1) at Generator.throw (<anonymous>) at rejected (apiNetworkProvider.js?5989:6:42)

This really happening only for some users, at the moment I have no idea why.

Do you have any hints, what might be wrong?

Thanks a lot!

[juliancwirko]

Hey, this is usually for wallets that aren't funded. And with Maiar App, it is simple to make that mistake.
For example, someone uses Maiar App with an address that doesn't have funds on the testnet or the devnet. They use it for the mainnet, but the testnet and devnet accounts for the same address are empty.

The error messages will be improved later.

[juliancwirko]

Have you reproduced it?

Maybe chain type mismatch. In the env variables

[Alannek1992]

Ok, I had a short session with one from the reporters and indeed he did not have any egold on the devnet. Sorry for that, my mistake. I thought that I checked that.

Another finding: When you log in via elrond web wallet - there you use maiar login the transaction cannot be signed. This is then the message in elrond wallet:

[juliancwirko]

@Alannek1992 I'll check that later, but I wonder why one would like to do that and not directly login using the maiar app ;)
does it work like that with, for example, maiar.exchange? I haven't tested yet.

[Alannek1992]

Yea, lets say it is not very common use case. But still it is a bug. I checked that and the problem seems to be occuring also in other places. So sorry for disturbing with this one.

If it is okay for you then I would do the following conclusion. It seems like your handling is correct, the problem was most likely insufficient balance. But let me list some of the things I found and want to ask.

1. Error handling - as you mentioned - you gonna improve that. That would be fantastic.
2. What is the optimal way in your opinion to check the transaction result? Lets assume an endpoint, which is returning u64 as a successful response. How would you parse that? So far I figured out the solution with checking the transaction on network using network provider and then using the result parser:

    const parseBuyCardSCResponse = async (txHash: TransactionHash) => {
      const apiNetworkProvider =
        getNetworkState<ApiNetworkProvider>("apiNetworkProvider");
      let parser = new ResultsParser();
      let transactionOnNetwork = await apiNetworkProvider.getTransaction(
        txHash.toString()
      );
      if (transactionOnNetwork.status.isFailed()) {
        setScTransactionResult({
          status: "fail",
          transactionHash: txHash.hex(),
        });
      }
      if (
        transactionOnNetwork.isCompleted &&
        transactionOnNetwork.status.isSuccessful()
      ) {
        try {
          const { values } = parser.parseUntypedOutcome(transactionOnNetwork);
          setScTransactionResult({
            status: "success",
            cardNonce: values[0]?.readUInt8(),
            transactionHash: txHash.hex(),
          });
        } catch {
 // handling the parsing failure - sometimes the transactionOnNetwork seems to be completed, but in reality it is still pending
 // my suspicious is that it could be a problem with MultiESDT transaction and mismatch
        }
      }
    };
    if (transaction) {
      parseBuyCardSCResponse(transaction.getHash());
    }

  }, [ transaction]);

3. Caching - thats the problem in general. It seems that a lot of stuff is being cached in browser and in some circumstances it can be problematic. Also sometimes I simply logged into different application and the login remained also in your dapp-template running demo example. Can you give me some tips/best practices how to handle such situations? e.g. Invalidating cache in some circumstances etc.

Thanks a lot for your answer and have a nice evening!

PS -> so far the best dapp template I found! I especially appreciate the lightweight and easy adaptability. Its written very well and organized thus it makes that easy to understand.

[juliancwirko]

Hey, very good questions. I need to note some of them as improvements in the todo list :)

As for the result parsing, the dapp uses simple int and string endpoints in useScQuery. There is no solution for more complicated structures yet. You can also check the TransactionWatcher for states. The best would be to check the docs on querying the smart contracts, contract interactions and waiting for transactions competition.

As for the caching, you're right. If you use two separate applications that use this template, they could read from the same local storage, there is an expiration mechanism implemented, but of course, it isn't enough. The simplest solution would be to save the hostname and invalidate it based on that. I will add this to the list.

[Alannek1992]

Thanks a lot for your reply and taking care of some points.

I ll check the TransactionWatcher, that seems to be very promising for my use case.

[juliancwirko]

Yes, I think the Transaction Watcher is the best for that. After the update to erdjs 10, there were changes, and catching the transaction status should be more accurate.