Transaction broadcasted and then not found

æpp Development
#16

You lucky dude! :joy:
Ok, someone will jump in I hope

#17

What exactly do you want to know ? :slight_smile: How to distinguish successful and failed contract deployments? :slight_smile:

1 Like
#18

Hey Nikita! Here’s a c/p from one of my previous replies:

  • After posting the transaction, what is the correct way then to await for transaction to actually get included in the chain? Should I just wait for every new key block and try to fetch the tx info (as you’ve said, this lasted for 3 hours in my case)? Is there a proper way to do this using js-sdk?
  • If I’m creating a contract , I’m only safe to interact with the contract once the creation transaction is provably included in the chain?
  • If I’d like to post more then 1 transaction from the same wallet (transactions are not related and order of execution does not matter) can I do this safely? Or I have to go one by one, one per keyblock?

Don’t know if these are clear enough, or actually make any sense… Thanks for any help or info you can provide!

#19

easy :slight_smile:

After posting the transaction, what is the correct way then to await for transaction to actually get included in the chain?

If you use the JS SDK’s native way of calling contracts, it returns a promise once the transaction has successfully been included in a microblock, no need to manually wait for keyblocks here except if you want to make sure you have a minimum block depth.

If I’m creating a contract , I’m only safe to interact with the contract once the creation transaction is provably included in the chain?

Yes :slight_smile:

If I’d like to post more then 1 transaction from the same wallet…

…then you need to wait for the first one to get mined before you send the second one, because the nonce of each transaction is unique and must get mined in a consecutive order. So tx nonce 2 must come after 1, or else it will get rejected.

A hint for the first question: I’ve included a code generator in AEstudio, you can use its output as a working example:

  1. Deploy a contract, 2. scroll to your function of choice and enter its parameters if necessary, 3. click:
    image

Then you can chose to see the code for SDK setup, contract deployment and function calling , or deactivate tickboxes at the top to see only the desired part (e.g. only contract function calling)

2 Likes
#20

Thanks mate. aestudio looks great, didn’t know about that one!

2 Likes
#21

So the rabbit whole lead me to a certain race condition in nodes communication. There was a lot of digging and eventually I was able to expose this an actually issue in a reproducible test. All tracked and already fixed in this PR. The fix would be deployed in the next release.

In advance: I have no proof this is what we are facing on main net. It is extremely hard to debug in such distributed environment, especially we don’t have any access to the interesting logs. What I am sure is that this is a legit bug scenario and it would be fixed on main net soon.

6 Likes
Users withdraw Ae on the Gate exchange. Because multiple users reported that the withdrawal failed due to the rollback of microblocks, Gate has announced that it will stop withdrawing AE
#22

That’s great news, thanks for all the hard work :rocket:

2 Likes
#23

Thanks for reporting it :slight_smile: Those race conditions are notoriously hard to detect and fix, so let’s see if this fixes it :slight_smile:

1 Like
#24

Hey, I have one more question but I won’t spam with new threads.
Some of my transactions take blocks and blocks before ending up in the chain. I’m tracking one of my transactions now and it’s been almost two hours when it finally it got mined. I’ve checked all the preconditions and transaction looks ok. This is something I’ve started noticing in the past few weeks. Is this related with variable hash rate? Can I do anything about this? Set a bigger gas price, or something. This is slowly killing my UX as the user sees pending transaction on frontend and this can last for hours…

2 Likes
#25

hey @filip, that is actually a very good question you have there, it would actually be wort a new thread but lets keep it here. did this phenomenon occur only when sending the TX through SuperheroWallet or directly through the JS SDK or in both cases ? Actually, in both cases you should get a reasonably well gas price estimation automatically, but you can also always set a higher gas price yourself.

#26

I broadcast transactions using js-sdk, the usual . sendTransaction() method, with the default configuration. And I’ve done this on the mainnet/testnet for some time now, but only recently I’ve started noticing issues… Yeah I can try and double the gas price, I know the default value is 1e9, but I was always told that there is no need to change this value. Do you have any other suggestions? Thanks mate!

2 Likes
#27

maybe @dimitar.chain knows whether the miners started having different gas prices which confuse the SDK’s gas price estimation or something ? did @philipp.chain run into this issue ?

#28

I just experienced the a similar issue with my NameUpdateTx:

  • th_2HBR5mqiH23j1zUZK6mMbFGJFvMBkKNnqPvhKuPSL6qH1e3UGE

initially it was included in block 403530, then it was dropped and finally it was included in block 403534.

2 Likes
#29

Ok, so I see 2 things now:

  1. The initial reports were that transaction is orphaned and then gone forever. This seems to be fixed with the introduction of release 5.10.1. Now orphaned transactions are reincluded again, only later on. Although this hurts finality, it seems like an issue had indeed been fixed but there is yet another one to track.
  2. So far we only had “the transaction is gone forever” which made the tracking of the issue really hard. Now we have some data, investigating generations 403530 - 403534 provides us with some clues what might be going on. I have 2 ideas I’d like to test, will keep you all updated.
2 Likes
#30

Awesome! If you need more data, here’s another transaction hash:
th_hpJx1bEr28bh6dcPrZStTuJqpNCdKREeXRDdPDXSiZHdoEdRu

I tracked this one, and it went through the series of transitions: being included at height N only to be excluded moments later (height: -1), then again included in N+1 or N+2 and so on, you get the point. After few transitions, it eventually got mined and included in the chain at height 401597. This might be useful for your research. Let me know if I can help in any other way, cheers!

2 Likes
#31

Yes, this was really valuable, thank you. This excluded a few possibilities…

#32

kk. also happening now with regular spendTx,

th_2ocFpJmorLtyLAkAwM34DkC1XoPQj6JQnQqwWLs47G32nVy9Je

Just leaving this here, maybe you can get use of it

1 Like
#33

Just to let you know, my transactions are now failing regularly. Can’t even spendTx, tried over baseaepp, arkane wallet, everything. Can you confirm? Did you try sending Ae today/yesterday? Try spending and see what happens with the tx and balances

1 Like
#34

Yes, we are debugging this. We have a clue and it will be resolved soon.

5 Likes
#35

hope to see this fixed soon, thanks! =)

5 Likes