Skip to content

feat(storage): add batch piece deletion - #898

Open
hugomrdias wants to merge 1 commit into
masterfrom
hugomrdias/551-batch-piece-deletions
Open

feat(storage): add batch piece deletion#898
hugomrdias wants to merge 1 commit into
masterfrom
hugomrdias/551-batch-piece-deletions

Conversation

@hugomrdias

@hugomrdias hugomrdias commented Jul 22, 2026

Copy link
Copy Markdown
Member

Summary

  • add batched deletePieces and schedulePieceDeletions operations to synapse-core
  • expose StorageContext.deletePieces() while preserving the existing singular API as a compatibility wrapper
  • deduplicate IDs before signing and submission, enforce Curio batch/range limits, and preserve bigint precision in JSON requests
  • document PDPVerifier’s cumulative pending-removal limit and add core/SDK coverage

Why

The EIP-712 SchedulePieceRemovals authorization already supports multiple piece IDs, but the SDK only submitted one piece at a time. Curio PR filecoin-project/curio#1309 added a compatible pieceIds request field, allowing one authorization and one on-chain transaction to schedule up to 500 removals.

Closes #551.

Developer impact

Consumers can now call:

await context.deletePieces({ pieces: [1n, 2n, pieceCid] })

The existing deletePiece() and schedulePieceDeletion() APIs remain available and delegate to the plural implementations.

Validation

  • pnpm run build
  • pnpm test
  • pnpm run lint:fix in packages/synapse-core and packages/synapse-sdk
  • core: 836 passing
  • SDK: 277 passing, 7 pending

The root lint command still reports pre-existing accessibility errors in documentation SVG assets; no documentation assets are changed by this PR.

@github-project-automation github-project-automation Bot moved this to 📌 Triage in FOC Jul 22, 2026
@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

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

@hugomrdias
hugomrdias marked this pull request as ready for review July 22, 2026 16:49
@hugomrdias
hugomrdias requested a review from rvagg as a code owner July 22, 2026 16:49
@rjan90 rjan90 moved this from 📌 Triage to 🔎 Awaiting review in FOC Jul 22, 2026
@rjan90 rjan90 added this to the M4.5: GA Fast Follows milestone Jul 22, 2026
})
}

export namespace deletePiece {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

you could mark all of the items below here as @deprecated

Comment on lines +105 to +108
* 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,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* 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

Comment on lines +1158 to +1159
* Curio accepts at most 500 pieces per request. PDPVerifier also allows at
* most 2,000 cumulative queued removals until the next proving period.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* 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,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 🔎 Awaiting review

Development

Successfully merging this pull request may close these issues.

Add delete multiple pieces in one go

3 participants