-
Notifications
You must be signed in to change notification settings - Fork 33
Conversation
Thanks @sparrowDom for working on this ! |
@franckc yup I guess this is currently more in a suggestion/proof of concept stage. |
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.
I'm ok with this for now, but this makes me think we definitely need to have an options
object for every method in the origin-js API. 2 arguments that would be placed in the options
object are confirmationCallback
and transactionHashCallback
.
@tyleryasaka agreed, have created an issue for unification of the api: #555 |
@tyleryasaka can you please take another look. Have added a more general |
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.
Thanks for working on this. Couple minor comments inline.
Also, could you add a unit test for the new functionality you are adding ? probably under test/resource_users.test.js
src/services/contract-service.js
Outdated
confirmationCallback(confirmations, { | ||
transactionHash: transactionInfo.hash | ||
}) | ||
// do checks untill 5 block confirmations |
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.
typo: "until"
nit: let's define 5 as a constant. Like NUM_CONFIRMATIONS
@@ -5,8 +5,8 @@ class Users { | |||
this.resolver = new UsersResolver({ contractService, ipfsService }) | |||
} | |||
|
|||
async set({ profile, attestations = [] }) { | |||
return this.resolver.set({ profile, attestations }) | |||
async set({ profile, attestations = [], options = {}}) { |
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.
nit: can we document as a comment what options are available ?
@franckc thanks for reminding me about tests. Inline comments are addressed and a test added. |
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.
Thanks for integrating my feedback and adding a unit test. One comment inline regarding test.
Sorry for being so picky, this is a pretty critical area of our codebase and I want to make sure we are really thorough...
test/resource_users.test.js
Outdated
}) | ||
|
||
expect(transactionHash).to.startsWith('0x') | ||
expect(confCount).is.a('number') |
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.
Isn't there a possible race condition here since it is not guaranteed the confirmationCallback will get called before this line is executed ?
One possible way to test callbacks I think is to put the test code within the callback itself. See for ex: https://gist.github.com/eswak/c54989f05c6f2ce4be00
Maybe something along the lines of
confirmationCallback: (confirmationCount, transactionReceipt) => {
expect(confirmationCount).is.a('number')
expect(trReceipt).is.a('object')
if (confirmationCount == NUMBER_CONFIRMATIONS_TO_REPORT) {
// this test is done, go to the next one
done()
}
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.
Ahh yes thanks @franckc . The approach with a done() callback is much better.
@@ -13,6 +13,7 @@ import bs58 from 'bs58' | |||
import Web3 from 'web3' | |||
|
|||
const emptyAddress = '0x0000000000000000000000000000000000000000' | |||
const NUMBER_CONFIRMATIONS_TO_REPORT = 20 |
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.
Is 20 a bit too high ? I thought typically 6 to 10 confirmations is good ? Maybe we pick 10 ?
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.
Yeah I also thought that initially and had it set to 5
. Then I observed that DApp marks transaction as confirmed after 12
confirmations ( https://github.com/OriginProtocol/origin-dapp/blob/master/src/components/dropdowns/transactions.js#L8 ). So I took that information and applied some margin just to be safe. So if we are to reduce this 20 it needs to be at least bigger than 12...
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.
Ok. Sg. Let's keep 20 for now then. Thanks for the details :)
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.
My reason for 1️⃣:two:: https://ethereum.stackexchange.com/a/3009/42177
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.
Thanks for explanation @micahalcorn
@@ -239,6 +277,7 @@ class ContractService { | |||
.send(opts) | |||
.on('receipt', resolve) | |||
.on('confirmation', confirmationCallback) |
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.
Won't we have same issue here mentioned in the deploy method that confirmationCallback does not get triggered ? Are we relying on this callback anywhere in our DApp or origin-js codebase ? If yes let's fix it (ok to do in separate PR), if no could we at least add a comment to warn caller that this is currently not working ?
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.
Interestingly when doing an Ethereum transaction confirmation callback is working, but when deploying a contract it is not. That is why the workaround is implemented only in the deploy
function a few lines above.
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.
Got it. Thanks for being thorough.
@franckc responded to comments and improved the test as you have proposed. And please don't hold back on the Pull Request comments. Each comment results either in clearing up confusion, improving the code base and/or improving coding skills. For that reason I prefer as many comments as possible. |
…/origin-js into sparrowDom/tranactionHash
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.
Nice work sir ! LGTM
Checklist:
Description:
**Connected PR: ** OriginProtocol/origin#577