Skip to content
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

Feat/no block chain ops #190

Merged
merged 9 commits into from
Apr 15, 2020
Merged

Feat/no block chain ops #190

merged 9 commits into from
Apr 15, 2020

Conversation

shannonwells
Copy link
Contributor

@shannonwells shannonwells commented Apr 13, 2020

Closes #69 Retrieval should not block on chain operations

@shannonwells shannonwells force-pushed the feat/no-block-chain-ops branch from 218d235 to 3b4659d Compare April 13, 2020 23:50
@codecov-io
Copy link

codecov-io commented Apr 13, 2020

Codecov Report

Merging #190 into master will increase coverage by 0.30%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #190      +/-   ##
==========================================
+ Coverage   67.83%   68.13%   +0.30%     
==========================================
  Files          38       39       +1     
  Lines        2070     2108      +38     
==========================================
+ Hits         1404     1436      +32     
- Misses        563      569       +6     
  Partials      103      103              
Impacted Files Coverage Δ
retrievalmarket/types.go 26.48% <ø> (ø)
retrievalmarket/impl/clientstates/client_fsm.go 100.00% <100.00%> (ø)
retrievalmarket/impl/clientstates/client_states.go 84.12% <100.00%> (+2.60%) ⬆️
storagemarket/types.go 33.34% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e232e40...84823dc. Read the comment docs.

@shannonwells shannonwells marked this pull request as ready for review April 14, 2020 16:58
Copy link
Collaborator

@hannahhoward hannahhoward left a comment

Choose a reason for hiding this comment

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

I think we have a misunderstanding about what the add funds flow looks like.

Regardless of what flow I use, I have no actual payment info when I start the deal.
When the deal is accepted, I go to DealStatusAccepted, and call GetOrCreatePaymentChannel.
If I previously created a separate transaction (i.e. another retrieval deal), GetOrCreatePaymentChannel will return that payment channel, at which point I need to save it in the deal, and wait for the adding fund message to process.
When the adding funds message finishes, I need to still create a new lane for this deal. And save that information.

Then the deal proceeds the same as it would from DealStatePaymentChannelReady

I've put what I believe are the various corrections needed to do this flow, but I think the first step is to have the integration test have a test case where it specifically tests the add flow. This will help reveal if we are doing it right.

Copy link
Collaborator

@hannahhoward hannahhoward left a comment

Choose a reason for hiding this comment

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

LGTM! Awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Retrieval Should Not Block on Chain Operations
3 participants