-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
passing error from sendTx as response of send raw tx #218
Conversation
Codecov Report
@@ Coverage Diff @@
## master #218 +/- ##
==========================================
+ Coverage 94.46% 94.47% +0.01%
==========================================
Files 70 70
Lines 1030 1032 +2
Branches 193 193
==========================================
+ Hits 973 975 +2
Misses 51 51
Partials 6 6
Continue to review full report at Codecov.
|
don't you break the compatibility with Ethereum RPC by changing the response? https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendrawtransaction |
return [false, e.toString()]; | ||
let err = e.toString(); | ||
if (err === '[object Object]') { | ||
err = JSON.stringify(e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @johannbarbie . We should be smarter and add some error messages to the tx handlers. Also we don't know if that could be a security issue if we return the whole stringified object 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree with you but I was not sure how to do batter
@johannbarbie Do you think it's better just to send error instead of tx hash in case there is an error?
@pinkiebell The only other way I see it is to find out why vmerror
is not thrown as proper exception and fix it there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it's better just to send error instead of tx hash in case there is an error?
yes, the user knows the txHash anyways .
What he really cares about is the moment when the tx is included.
i think the way it works in ethereum is 2 steps:
- from
sendRawTransaction()
you get a txHash back - with the txHash you use
getTransactionReceipt()
to wait for the block to be mined
https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactionreceipt
i think we should follow the API, and start thinking about receipts, but outside of this bounty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, the user knows the txHash anyways
ok, fixed that
and agree, it would be great if we can get error by calling getTransactionReceipt
tx ash in case of success or error in case of an error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- please add unit tests
- do not commit
lotion/package.json
andlotion/yarn.lock
— these aren't needed
this is not compatible with changes introduced in #241 |
fixes #207
sendRawTransaction
now returns an object{hash, error}
witherror: 0
in case of success