-
Notifications
You must be signed in to change notification settings - Fork 16
feat: support streaming uploads #287
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -119,6 +119,10 @@ With [Filecoin Pin](#filecoin-pin), the Piece is the [CAR](#car) file itself; an | |
|
|
||
| PieceCID, or "CommP" (Commitment of Piece), is a specific form of [CID](#cid) used in Filecoin to commit Merkle proofs of large _pieces_ of data on chain. A PieceCID includes a digest of the contiguous bytes, with no special handling of any internal format or packing (including CAR formats containing IPFS data). It uses a modified form of SHA2-256 internally, and further details can be found in [FRC-0069](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0069.md). PieceCID is a variant of CID specifically for use in Filecoin's proof system, and will differ from the CIDs used in IPFS. When presented in standard base32 format, it will begin with the characters `bafkzcib` and be between 64 and 65 characters long. | ||
|
|
||
| ## Streaming Uploads | ||
|
|
||
| [Filecoin Pin](#filecoin-pin) streams CAR data to [Service Providers](#service-provider) via [Synapse](#synapse), so files are not buffered fully in memory during upload. The maximum supported piece size is bounded by the Synapse SDK and SP configuration (tracked in https://github.com/FilOzone/synapse-sdk/issues/110). | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. needs tweaking as well, in the browser we buffer up to 1GiB (1016MiB) in fact, I don't think we even have early limits on it, so potentially someone could request an |
||
|
|
||
| ## `/piece` Retrieval | ||
|
|
||
| This is a Filecoin-defined retrieval specification outlined in https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0066.md. It is for retrieving pieces by [Piece CID](#piece-cid), optionally taking a byte range specified by standard HTTP request format. Piece retrieval is useful for downloading the bytes _as they are stored and proven_ in Filecoin, either to request the original non-IPFS data stored, or downloading the CAR format data generated by Filecoin Pin. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -90,11 +90,19 @@ vi.mock('../../utils/cli-helpers.js', () => ({ | |
| })) | ||
|
|
||
| // We need to partially mock fs/promises to keep real file operations for test setup | ||
| // but mock readFile for the CAR reading part | ||
| // but mock readFile/stat for the CAR handling part | ||
| vi.mock('node:fs/promises', async () => { | ||
| const actual = await vi.importActual<typeof import('node:fs/promises')>('node:fs/promises') | ||
| return { | ||
| ...actual, | ||
| stat: vi.fn((path: string) => { | ||
| if (path === '/tmp/test.car') { | ||
| return Promise.resolve({ | ||
| size: 1024, | ||
| } as any) | ||
| } | ||
| return actual.stat(path as any) | ||
| }), | ||
|
Comment on lines
92
to
+105
|
||
| readFile: vi.fn((path: string) => { | ||
| // If it's reading the temp CAR, return mock data | ||
| if (path === '/tmp/test.car') { | ||
|
|
||
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.
This is not actually true though, there's still an interim
createCarFromPathgoing on here; no buffering in memory but "as we build the CAR, we stream it" isn't how it works.But, I've been intending to fix this. It means changing how we generate the CARs but we don't actually need the CAR to be properly ordered or have a correct header. Let me follow-up with a PR to this cause it's been on my mental list to solve since the begining, without actually describing it in an issue (I think).
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.
Actually no, it's a bit more complicated because of metadata needing the root CID, but that will become easily fixable soon. I've documented it all in #288; so this PR is fine if you just tweak this sentence and we can use #288 as a follow-up when we can get to it (when FilOzone/synapse-sdk#494 is done).