search

nanobox-cc / nano-client

A simple to use Node/browser client for the Nano network
2 stars 1 forks source link

blocks not getting confirmed for existing accounts with previous unconfirmed transactions #18

Closed OmarB97 closed 3 years ago

OmarB97 commented 3 years ago

Link to my send() API call on the server side:

https://github.com/OmarB97/trynano-server/blob/c6cd7a2b999e0218dd106d76ad5e0a1175860bd7/index.js#L276-L284

Client site URL:

https://trynano.io

Most recent site version (currently in separate branch with PR):

https://deploy-preview-13--pedantic-noether-b86f9d.netlify.app/

Link to my faucet account on NanoLooker which is trying to send the Nano:

https://nanolooker.com/account/nano_1r71ir93w6ymq9bmjbbz7zmqngj54uhgcdjgrjzcpk5bog3rs5t7ijh47y7w

This call seems to be successful from the response that is returned, but I checked NanoLooker and I don't see any send transactions, and I'm also not seeing any send/receive confirmation subscriptions coming in on the client browser app side. It seems like everything else is working, except for this call. Is there some underlying bug with the .send() API? It's the version where you specify the send amount, not sendMax().

LMK if there's any additional info I can provide which can help here. Thanks!

OmarB97 commented 3 years ago

I thought about this more, I'm not sure it's actually related to the send() API, but rather it could be due a long list of blocks unconfirmed by the network still for this specific nano account. And no new blocks are going to be confirmed until the previous blocks are confirmed, is my guess?

I read on reddit that new transactions on accounts are going through immediately, but accounts with existing transactions may still be pending, so that might help explain why the newly generated accounts are able to send/receive with no issues, but sending/receiving on the FAUCET address is having trouble.

aspic commented 3 years ago

First of all thanks for this thorough report! Yep, you're correct, there still a fair amount of transactions that still need to be confirmed by the network. Did you try opening a new account and test with that?

The sendMax()-call is using the same underlying processSend as the send()-call, so there is o difference in those two calls (other than the amount) :-)

OmarB97 commented 3 years ago

First of all thanks for this thorough report! Yep, you're correct, there still a fair amount of transactions that still need to be confirmed by the network. Did you try opening a new account and test with that?

The sendMax()-call is using the same underlying processSend as the send()-call, so there is o difference in those two calls (other than the amount) :-)

Yup that makes sense! I think to unblock I will set up a second temporary faucet address just so users don't hang waiting for the confirmation, and once the network has fully caught up with the backlog of unconfirmed blocks, I'll switch it back to the regular faucet account.

OmarB97 commented 3 years ago

Update: changed to a new account and the faucet is now working again!

aspic commented 3 years ago

Thanks! Closing this one then. Implementing dynamic pow in the client will help some with this as well (in future scenarios when there's much traffic in the network).