Simple signing queue, confirmation APIs exposed in signer WebSockets. #1182
Conversation
Conflicts: parity/signer.rs
Conflicts: rpc/src/v1/impls/eth.rs rpc/src/v1/tests/mocked/eth.rs rpc/src/v1/traits/eth.rs
|
doesn't interact nicely with the RPC |
[ci skip]
| .and_then(|(request, )| { | ||
| let queue = take_weak!(self.queue); | ||
| queue.add_request(request); | ||
| // TODO [ToDr] Block and wait for confirmation? |
There was a problem hiding this comment.
yes - current behaviour will break dapps.
in a future PR need to provide a callback-orientated RPC that does a similar job.
There was a problem hiding this comment.
I have it already fixed on signing-wsnotification branch.
It's waiting for up to 20 seconds and the returns 0x0.
Actually it says here that 0x0 is a valid response if "transaction is not yet available" (whatever that means)
https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendtransaction
DATA, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available.
There was a problem hiding this comment.
Returning the zero hash here is an acceptable option for the time being given that the spec seems to allow it, and especially since there is a fix pending in another branch.
|
looks good aside from the return value to |
gavofyork
added
A4-gotissues 💥
|
Any ideas how to solve waiting for confirmation issue (apart from waiting with timeout which will be done in a next PR when this get's merged)? |
Conflicts: rpc/src/v1/tests/eth.rs
--signeris disabled it should just use current implementation (compatibility, see:EthSigningUnsafeClient)EthSigningQueueClient, additionalpersonal_*APIs are exposed over WebSockets (PersonalSigner)parity/rpc_apis.rsand used inrpc, dapps and signer.