Feat/snap deals storage #7615
Feat/snap deals storage #7615
Conversation
24bc634 to
1f79db0
Compare
2e37de1 to
797c15b
Compare
Codecov Report
@@ Coverage Diff @@
## next #7615 +/- ##
==========================================
+ Coverage 39.50% 39.56% +0.05%
==========================================
Files 646 646
Lines 68376 68582 +206
==========================================
+ Hits 27015 27136 +121
- Misses 36722 36772 +50
- Partials 4639 4674 +35
Continue to review full report at Codecov.
|
7ef1652 to
7d2b3f0
Compare
| // for _, path := range t.StoragePaths { | ||
| // if err := os.RemoveAll(path.Path); err != nil { | ||
| // fmt.Println("Cleanup error:", err) | ||
| // } | ||
| // } |
There was a problem hiding this comment.
Bring back before merging (could add an env var to turn this cleanup off)
| case "2k": | ||
| case "8M": |
There was a problem hiding this comment.
It should be covered by the default above
| ctx, cancel := context.WithCancel(ctx) | ||
| defer cancel() | ||
|
|
||
| wk, wait, cancel, err := m.getWork(ctx, sealtasks.TTProveReplicaUpdate1, sector, sectorKey, newSealed, newUnsealed) |
There was a problem hiding this comment.
Wait, doesn't this cancel shadow the cancel above, and don't we end up calling the getWork cancel twice, and not calling context.WithCancel?
There was a problem hiding this comment.
(I realize we're doing the same above)
There was a problem hiding this comment.
I think the first cancel function is captured before shadowing by the first defer. I wasn't sure and made this example to get to this conclusion: https://go.dev/play/p/5IAnJuFg69N. I think that means this pattern is ok. Make sense to you?
|
(we also should bump minor worker/miner API versions ( |
Good call out. I don't know the workflow for rebasing next on master but will do this when that time comes. |
WIP introducing snap deals support for sector storage by adding a new file type.
Needs filecoin-project/specs-storage#17