search

polkadot-js / api

Promise and RxJS APIs around Polkadot and Substrate based chains via RPC calls. It is dynamically generated based on what the Substrate runtime provides in terms of metadata.
Apache License 2.0
1.07k stars 349 forks source link

unable to transfer balance #1268

Closed coolcode closed 5 years ago

coolcode commented 5 years ago

I follow the sample 'Make a simple transfer' https://polkadot.js.org/api/examples/promise/06_make_transfer/

But it fails and here is the error message:

1014: Priority is too low: (12673 vs 138) (The transa) 2019-08-04 19:58:07 RPC-CORE: submitExtrinsic (extrinsic: Extrinsic): Hash:: 1014: Priority is too low: (12673 vs 138) (The transa) ExtError: submitExtrinsic (extrinsic: Extrinsic): Hash:: 1014: Priority is too low: (12673 vs 138) (The transa) at call (/Users/bruce/projects/rust/substrate-rpc-test/node_modules/@polkadot/rpc-core/index.js:150:15) at processTicksAndRejections (internal/process/task_queues.js:86:5) TypeError: Cannot read property 'toHex' of undefined at main (/Users/bruce/projects/rust/substrate-rpc-test/tran.js:25:47) at processTicksAndRejections (internal/process/task_queues.js:86:5)

coolcode commented 5 years ago

new error message when running in a new chain: $ node tran.js ExtError: @polkadot/wasm-crypto has not been initialized at assert (/Users/bruce/projects/rust/substrate-rpc-test/node_modules/@polkadot/keyring/node_modules/@polkadot/util/assert.js:47:9) at params (/Users/bruce/projects/rust/substrate-rpc-test/node_modules/@polkadot/keyring/node_modules/@polkadot/wasm-crypto/exports.js:13:7) at schnorrkelKeypairFromSeed (/Users/bruce/projects/rust/substrate-rpc-test/node_modules/@polkadot/keyring/node_modules/@polkadot/util-crypto/schnorrkel/keypair/fromSeed.js:25:71) at Keyring.createFromUri (/Users/bruce/projects/rust/substrate-rpc-test/node_modules/@polkadot/keyring/keyring.js:208:84) at Keyring.addFromUri (/Users/bruce/projects/rust/substrate-rpc-test/node_modules/@polkadot/keyring/keyring.js:169:30) at main (/Users/bruce/projects/rust/substrate-rpc-test/tran.js:17:25) at processTicksAndRejections (internal/process/task_queues.js:86:5) ✨ Done in 0.97s.

coolcode commented 5 years ago

It works by referring this issue #1033 Here is the source code.

/* eslint-disable @typescript-eslint/no-var-requires */
// Import the API, Keyring and some utility functions
const { ApiPromise } = require('@polkadot/api');
const { Keyring } = require('@polkadot/keyring');
const { cryptoWaitReady } = require('@polkadot/util-crypto') ;

const BOB = '5HpG9w8EBLe5XCrbczpwq5TSXvedjrBGCwqxK1iQ7qUsSWFc';

async function main () {    

  await cryptoWaitReady();
  // Instantiate the API
  const api = await ApiPromise.create();

  // Constuct the keying after the API (crypto has an async init)
  const keyring = new Keyring({ type: 'sr25519' });

  // Add alice to our keyring with a hard-deived path (empty phrase, so uses dev)
  const alice = keyring.addFromUri('//Alice');

  // Create a extrinsic, transferring 12345 units to Bob
  const transfer = api.tx.balances.transfer(BOB, 12);

  // Sign and send the transaction using our account
  const hash = await transfer.signAndSend(alice);

  console.log('Transfer sent with hash', hash.toHex());
}

main().catch(console.error).finally(() => process.exit());
jacogr commented 5 years ago

The above is weird, await ApiPromise.create(); actually calls cryptoWaitReady(); internally - will have to take a look if something there is missing at this point.

As for the original error - it means that the nonce of the transaction and what is expected on-chain is different. So max in pool vs send it mismatching. (And the difference is quite large)

xlc commented 5 years ago

1014: Priority is too low: (12673 vs 138) (The transa) means nonce value is too low. Priority in this case is actually transaction size. So you have submitted a large transaction (12673 bytes) and later submitted a small transaction (138 bytes) with same nonce value before the previous one is confirmed.

ghost commented 5 years ago

Our faucet is failing with similar error. Watching this issue.

jacogr commented 5 years ago

Make sure that nonce are not re-used, nothing much else’s that can be done.

For 2.x chains, eg. Kusama, this will help - https://github.com/polkadot-js/api/issues/1342 - nonce can be properly deduced from what is in the queue in addition to state.

ghost commented 5 years ago

We are seeing the issue on POC-3 Website. So my guess is it's not related to just nonce and there is nothing in the queue. @jacogr can you checkout this video and let me know what do you think ?

jacogr commented 5 years ago

What is the address for the sender - there are a bunch of transactions in the pending pool on Alexander, some mortal, some not. So that could help to see what the node does - it def. thinks that it already has the specific transaction.

Found it from the video. So looking at the pending queue on Alex via https://polkadot.js.org/apps/#/explorer/node I see at least these -

image

Scrolling down a bit, some more -

image

And -

image

And there are more...

So the error you are seeing, well, it is correct - there are already extrinsics with those nonces in the queue. They are all mortal, so should have been cleared by the node when turning invalid.

jacogr commented 5 years ago

The RPC node on Alex was restarted, clearing the queue. There is a bug where old transactions (ie. Mortals that have been expired) are not re-checked. So they stay in the queue, but new ones won’t be accepted.

There will be a PR in substrate to address this issue.

ghost commented 5 years ago

Now transfer is working for account 5Cdpp6okrULs2M8h1WC6uxyQmRCzMyP5fxYuKda8RTZwmnrr. Could you send me related substrate issue ?

jacogr commented 5 years ago

@kushptlapigarage Check the linked PR.

jacogr commented 5 years ago

As of 0.93.1 the API will now use the account_nextIndex RPC (if available) to determine the next nonce. (Not aware of any chains that . ship with this enabled yet though, Kusama which is very new does not have it enabled)

If not enabled, it falls back to using the accountNonce as it has been doing (which means transactions in the pool is not taken into account)

ghost commented 5 years ago

This issue has resurfaced with the same account. We fixed https://faucets.blockxlabs.com by creating a new account

Here is the error I see in browser console RPC-CORE: submitAndWatchExtrinsic (extrinsic: Extrinsic): ExtrinsicStatus:: 1014: Priority is too low: (147 vs 147) (The transa)

jacogr commented 5 years ago

Ok, this is not an API issue, so we are getting the wrong eyes on this by posting in this issue - check the queue on Alexander... There are tons of transactions that are just "stuck" (not getting cleared, the same issue that was fixed in substrate 2.x & Kusama) Small sample -

image

If this does pop up, I would suggest mentioning it is chat so one of the ops guys can manually jump in and do a restart. (There is nothing else that can be done here, if the transactions are not added to the block before they expire, it ends up being, erm, problematic)

PS: I'm pinging an ops person for the latest occurence.