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

Retrieval Deals, Spec V0 #37

Merged
merged 5 commits into from
Jan 14, 2020
Merged

Conversation

hannahhoward
Copy link
Collaborator

@hannahhoward hannahhoward commented Jan 10, 2020

Goals

Implement spec v0 retrieval (unixFS only)

Implementation

  • Rewrite write retrieval execution as a state machine
    • Test state handlers
  • handle payments when needed
  • handle absorb and verify blocks as needed
  • utilize block consumer / verifiers from old pre-spec

For Discussion

Note the state transitions return a state modifier -- the intent is ultimately to have that be a state transition function in a real FSM type module
Also there's a likely hood states themselves will get written to disk for resuming requests.

@hannahhoward hannahhoward changed the title Retrieval Deal, Client Spec V0 Retrieval Deals, Spec V0 Jan 14, 2020
Copy link
Contributor

@shannonwells shannonwells left a comment

Choose a reason for hiding this comment

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

I have the one question about double subscriber notification and the rest are strictly a judgment call. I didn't mark it request changes in case I missed something.

rmnet "github.com/filecoin-project/go-fil-markets/retrievalmarket/network"
"github.com/filecoin-project/go-fil-markets/shared/tokenamount"

"golang.org/x/xerrors"
Copy link
Contributor

Choose a reason for hiding this comment

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

Is xerrors something we should standardize on? I've been using github.com/pkg/errors. I noticed cbor_gen uses it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We should use xerrors ideally, and wrap errors whenever additional information might prove useful

}
c.notifySubscribers(retrievalmarket.ClientEventProgress, dealState)
}
if retrievalmarket.IsTerminalSuccess(dealState.Status) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this right? It looks like if status is non-terminal, subscribers will be notified both of the status and then ClientEventError. Should there be a return above?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So the status at this line must be terminal -- cause the break in the above loop requires that.

And that notification for status inside the loop is below the break so that the "in progress" notification only goes out if the status is not terminal after applying dealModifier.

my notion of how things will proceed in the loop based on the code above is:

  • at start of loop, status is non terminal
  • apply logic based on starting status
  • apply modifier for new status
  • check if new status is terminal, if so exit loop
  • notify in progress status update and start loop again, but only if status is non-terminal

and the code at the bottom is:
with terminal status that exited loop--

  • if success notify complete
  • if terminal error, notify error

Does that track with your understanding of this code?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok that makes sense.

})
f := clientstates.ProcessPaymentRequested(ctx, fe, *dealState)
f(dealState)
require.Empty(t, dealState.Message)
Copy link
Contributor

Choose a reason for hiding this comment

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

These numbers don't have meaning just reading through the test - I had to search around to figure out where they came from. It would be helpful to compare with the test variables up above to compare, including totals, e.g.

require.Equal(t, dealState.BytesPaidFor, defaultTotalReceived)
require.Equal(t, dealState.CurrentInterval, defaultCurrentInterval+defaultIntervalIncrease)


t.Run("failure processing payment", func(t *testing.T) {
node := testnodes.NewTestRetrievalProviderNode()
message := "your money's no good here"
Copy link
Contributor

Choose a reason for hiding this comment

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

😸

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

💸

Sets up basic infrastructure for client deals
Contains remaining logic for processing payments and reading responses, on client side
update provider to spec v0 for deals, mirroring client ops
make clear what numbers expected in tests of payment processing mean for retrieval deals
@hannahhoward hannahhoward merged commit 8cf2e3b into master Jan 14, 2020
@hannahhoward hannahhoward deleted the feat/retrieval-deal-spec-v0 branch April 30, 2020 21:32
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.

2 participants