Method web3.personal.unlockAccount doesn't accept integer as unlock period parameter.
Example:
web3.personal.unlockAccount(eth_address, 'strongPassword', 10000)
returns ValueError:
ValueError: {u'message': u'invalid type: integer10000, expected a 0x-prefixed, hex-encoded number of type U128', u'code': -32602, u'data': None}
when using value in HEX :
web3.personal.unlockAccount(eth_address, 'strongPassword', 10000)
it works fine (returns True)
Presumably you meant that web3.personal.unlockAccount(eth_address, 'strongPassword', '0x2710') works as expected?
Yes! Apologies, copy paste fail.
@userpasta I'm having trouble reproducing this error when connecting to a geth node. There is also a test in test_personal_unlockAccount.py that explicitly uses an integer argument. On top of that, I tried with a hex-string for duration parameter and got the following error
web3.personal.unlockAccount(eth_address, 'strongPassword', "0x2710")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "web3/personal.py", line 85, in unlockAccount
[account, passphrase, duration],
File "web3/manager.py", line 96, in request_blocking
raise ValueError(response["error"])
ValueError: {u'message': u'invalid argument 2: json: cannot unmarshal string into Go value of type uint64', u'code': -32602}
What type of node are you connecting to? geth, testrpc, parity, etc...
Considering there is not explicit check in web3.py on the duration type and it is simply passed onto the provider, I'm guessing it has to do with a node implementation specific error.
@userpasta did you see my question above?
@djrtwo were you manually testing at the v3.9.0 tag? Maybe it got fixed in a later version
Apologies, was OoO.
@djrtwo I'm connected to the parity node. I was testing in v3.9.0. It's not a issue for me to provide the number in hex, but it variable type wasn't consistent with web3js, that's why Piper recommended to file a bug.
Oh, so it's node specific. Looks like a false alarm, feel free to close the bug.
If this is a problem when connecting to parity, then we still need to fix it.
If this is a problem that's fixed when updating Web3 to v3.15.0, then we should close it.
@userpasta can you try updating web3 and running again?
@carver It works with v3.15.0
Thanks! Closing for now. Please reopen if you can reproduce on a recent version.
Most helpful comment
Apologies, was OoO.
@djrtwo I'm connected to the parity node. I was testing in v3.9.0. It's not a issue for me to provide the number in hex, but it variable type wasn't consistent with web3js, that's why Piper recommended to file a bug.
Oh, so it's node specific. Looks like a false alarm, feel free to close the bug.