Console: Can't resend transaction with data, possibly due to de/coding issues

[veox]

System information

Geth version: 1.6.1-stable-021c3c28
OS & Version: Ubuntu 16.04.2 LTS
Commit hash: stable (see above)

Semi-expected behaviour

As described in the wiki, eth.resend() should allow changing the gasPrice of a "pending" transaction. This kind-of-works OK with a transaction created via eth.sendTransaction():

> eth.sendTransaction({from: eac, to: deaf, value: web3.toWei(0.01, 'ether'), gasPrice: web3.toWei(0.1, 'shannon')})
"<txhash1>"
> var pt = eth.pendingTransactions
> var tx = pt[1]
> eth.resend(tx, tx.gasPrice.toNumber() + 1, tx.gas)
"<txhash2>"

I'm saying "kind-of-works", since:

• the sorting order of txs listed by eth.pendingTransactions seem to escape me (the array is constructed from iterating through the tx pool, so perhaps there is no sorting?..); (EDIT: by nonce?..);
• .toNumber() is needed - tx.gasPrice type mutating?..

Unexpected behaviour

If a transaction is created by a call to a contract object, e.g.:

...
> var Cancelot = eth.contract(CancelotABI).at(CancelotAddress);
> Cancelot.withdraw({from: deaf, gas: 30000, gasPrice: web3.toWei(0.1, 'shannon')})
"<txhash1>"
> var pt = eth.pendingTransactions
> var tx = pt[1] // WHAT?..
> eth.resend(tx, tx.gasPrice.toNumber() + 1, tx.gas)
Error: Transaction <txhash-bogus> not found
    at web3.js:3104:20
    at web3.js:6191:15
    at web3.js:5004:36
    at <anonymous>:1:1

The <txhash-bogus> doesn't match any transactions currently returned by eth.pendingTransactions, so it fails. The hash comes from converting the tx provided in eth.resend(tx, ...) slightly earlier, which looks like the reason for this particular failure.

Possibly related

The latest changes (EDIT: that seem to be relevant to me) to internal/ethapi/api.go are from commit cf71f5c, part of PR #3475. Among other things, that replaced rpc.Hexnumber with hexutil.Uint, and similar.

That PR fixed issue #2438, about RPC responses not being prefixed with 0x.

I've noticed that the output of eth.pendingTransactions has gas, gasPrice, and a few others not encoded in this manner (in the console). However, txpool.content is - which seems inconsistent; the former is constructed from the latter, right?..

Also, after an eth.resend(tx, ...) the tx object, which had its gasPrice property as an integer, now has it encoded as a hex number in a string!

[veox]

Tested resending using Populus via IPC, works as expected. So, this seems likely limited to the console.

[karalabe]

Hey there! This is an interesting use case. On one hand it would be nice if the console printed user friendly values instead of hex strings for prices and whatnot, however your request is also perfectly valid that you should still be able to operate on them.

@bas-vk Any ideas if this is accidental or deliberate?

[ta20170412]

Also affected by this issue, as discovered after particular ICO and transactions congestion.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[veox]

I feel this should stay open if eth.resend() is to remain available. However, I haven't tried it since reporting this bug; instead keeping the re-send logic in an external application.

[tomislavr]

If is helps, changing property name input to data of tx from eth.pendingTransactions, and using it like that in eth.resend(...) gets the job done in the console - no Error: Transaction <txhash-bogus> not found problem.

[veox]

@tomislavr Yes, that's exactly what I'm doing in the "external application" mentioned previously.

[karalabe]

Does this till happen with master? We've changed some time ago Geth to accept both data and input, so mixing the two should not be relevant.

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have more relevant information or answers to our questions so that we can investigate further.