Skip to content
This repository has been archived by the owner on Jan 14, 2020. It is now read-only.

Sparrow dom/tranaction hash #546

Merged
merged 12 commits into from
Sep 27, 2018
Merged

Sparrow dom/tranaction hash #546

merged 12 commits into from
Sep 27, 2018

Conversation

sparrowDom
Copy link
Member

@sparrowDom sparrowDom commented Sep 25, 2018

Checklist:

  • Code contains relevant tests for the problem you are solving
  • Ensure all new and existing tests pass
  • Update any relevant READMEs and docs

Description:

**Connected PR: ** OriginProtocol/origin#577

@franckc
Copy link

franckc commented Sep 25, 2018

Thanks @sparrowDom for working on this !
I can review once the discussion regarding approach to take on DApp side is settled a bit more... regardinhttps://github.com/OriginProtocol/origin/pull/577

@sparrowDom
Copy link
Member Author

@franckc yup I guess this is currently more in a suggestion/proof of concept stage.

Copy link
Contributor

@tyleryasaka tyleryasaka left a 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.

@sparrowDom
Copy link
Member Author

@tyleryasaka agreed, have created an issue for unification of the api: #555

@sparrowDom
Copy link
Member Author

@tyleryasaka can you please take another look. Have added a more general options approach that could be used in unification api step that we will do some time later.

Copy link

@franckc franckc left a 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

confirmationCallback(confirmations, {
transactionHash: transactionInfo.hash
})
// do checks untill 5 block confirmations
Copy link

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 = {}}) {
Copy link

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 ?

@sparrowDom
Copy link
Member Author

@franckc thanks for reminding me about tests. Inline comments are addressed and a test added.

Copy link

@franckc franckc left a 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...

})

expect(transactionHash).to.startsWith('0x')
expect(confCount).is.a('number')
Copy link

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()
  }

Copy link
Member Author

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
Copy link

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 ?

Copy link
Member Author

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...

Copy link

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 :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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)
Copy link

@franckc franckc Sep 27, 2018

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 ?

Copy link
Member Author

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.

Copy link

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.

@sparrowDom
Copy link
Member Author

@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.

Copy link

@franckc franckc left a 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

@franckc franckc merged commit 8e6f238 into master Sep 27, 2018
@franckc franckc deleted the sparrowDom/tranactionHash branch September 27, 2018 17:01
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
p0 Blocking priority
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants