-
Notifications
You must be signed in to change notification settings - Fork 17
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
chore(client): basic query testing using mock net #83
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #83 +/- ##
==========================================
+ Coverage 44.34% 48.29% +3.94%
==========================================
Files 28 29 +1
Lines 2546 2578 +32
==========================================
+ Hits 1129 1245 +116
+ Misses 1371 1274 -97
- Partials 46 59 +13
|
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 would also argue that anything that runs on a mock net should live in an itest directory outside the hierarchy.
We should be ideally making the client have more abstract deps so it can be used independently.
I'm going to go ahead and merge cause it's certainly an improvement, but good feedback as you continue to make progress.
return err | ||
} | ||
|
||
mqn.server.SetStreamHandler(retrievalmarket.QueryProtocolID, func(s network.Stream) { |
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.
the complexity of this simple response points to a challenging long term issue when we build these -- I don't see how we respond to actual graphsync requests with filecoin retrieval negotiation happening on top without putting actual graphsync and the go-fil-markets retrieval server on top. Which don't get me wrong -- we can do, I just want to identify how hard that might end up being.
@@ -0,0 +1,236 @@ | |||
package client_test |
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 would also argue that anything that runs on a mock net should live in an itest directory outside the hierarchy. The solution for a test that lives in 'client' is to make it more injectable so we can unit test it.
I'm not religious about this though.
I've been working on some deeper testing as I iterate toward unixfs pathing (I really want to be able to do graph transfers to test that we're getting exactly the blocks we want). This is some of my initial forays into network-level testing.
Query
orQueryResult
the bindnode treatment so I did that in here but expect that to be extracted out to a go-markets-types repo in the near future; in the process I replaced the "rpc" stuff with some go-ipld-prime processing (using feat(dagcbor): mode to allow parsing undelimited streamed objects ipld/go-ipld-prime#490, hence the untagged dependency).