feat(storage): add batch piece deletion - #898
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
synapse-dev | b35b371 | Commit Preview URL Branch Preview URL |
Jul 22 2026, 04:43 PM |
| }) | ||
| } | ||
|
|
||
| export namespace deletePiece { |
There was a problem hiding this comment.
you could mark all of the items below here as @deprecated
| * PDPVerifier also limits a data set to 2,000 cumulative queued removals until | ||
| * its next proving period, so a valid batch can still fail when that queue is full. | ||
| */ | ||
| MAX_DELETE_PIECES_BATCH_SIZE: 500, |
There was a problem hiding this comment.
| * PDPVerifier also limits a data set to 2,000 cumulative queued removals until | |
| * its next proving period, so a valid batch can still fail when that queue is full. | |
| */ | |
| MAX_DELETE_PIECES_BATCH_SIZE: 500, | |
| * Curio also rejects requests (429) when the data set already has 200 or more | |
| * removals queued on-chain; the queue only drains at the next proving period. | |
| */ | |
| MAX_DELETE_PIECES_BATCH_SIZE: 200, |
see filecoin-project/curio#1372, it's slightly more nuanced than this but no need to overcomplicate it here
| * Curio accepts at most 500 pieces per request. PDPVerifier also allows at | ||
| * most 2,000 cumulative queued removals until the next proving period. |
There was a problem hiding this comment.
| * Curio accepts at most 500 pieces per request. PDPVerifier also allows at | |
| * most 2,000 cumulative queued removals until the next proving period. | |
| * Curio accepts at most 200 pieces per request and rejects requests (429) when | |
| * the data set already has 200 or more removals queued on-chain; the queue only | |
| * drains at the next proving period. |
also suggesting in these edits to leave out mention of PDPVerifier, it's a theoretical max and in practice it's been shown to not even be usable, so it "allows" but that doesn't work and will brick your data set
| retry: { | ||
| retries: options.retryCount, | ||
| minTimeout: options.retryDelay ?? RETRY_CONSTANTS.RETRY_DELAY, | ||
| shouldRetry: (ctx) => HttpError.is(ctx.error) && ctx.error.code === 429, |
There was a problem hiding this comment.
eh, retry on a 429 even though we're going to get that until the next proving period? probably not, we should just bork and report as an error
Summary
deletePiecesandschedulePieceDeletionsoperations to synapse-coreStorageContext.deletePieces()while preserving the existing singular API as a compatibility wrapperWhy
The EIP-712
SchedulePieceRemovalsauthorization already supports multiple piece IDs, but the SDK only submitted one piece at a time. Curio PR filecoin-project/curio#1309 added a compatiblepieceIdsrequest field, allowing one authorization and one on-chain transaction to schedule up to 500 removals.Closes #551.
Developer impact
Consumers can now call:
The existing
deletePiece()andschedulePieceDeletion()APIs remain available and delegate to the plural implementations.Validation
pnpm run buildpnpm testpnpm run lint:fixinpackages/synapse-coreandpackages/synapse-sdkThe root lint command still reports pre-existing accessibility errors in documentation SVG assets; no documentation assets are changed by this PR.