fix: add getScheduledRemovals method

[SgtPooki]

fix: add getScheduledRemovals method

Problem

There was a data consistency issue when removing pieces from datasets:

1. StorageContext.deletePiece() called the PDP server (Curio) to schedule removal
2. StorageContext.getPieces() queried the PDPVerifier contract to list pieces
3. This caused a mismatch where:

• After calling deletePiece(), the piece would be scheduled for removal in Curio's internal state, and the schedulePieceRemovals would occur immediately (as described in comment below)
• But getPieces() would still show the piece as active (reading from contract)
• The piece would only disappear from queries after Curio processed the removal and updated it's internal state

This created confusing UX where calling deletePiece() then immediately querying the dataset would still show the piece without insight about it pending removal.

Solution

Consumers can call getScheduledRemovals contract method via pdpVerifier

• Added pdpVerifier.getScheduledRemovals(). Consumers will need to call to discern whether pieces are pending removal or not

Changes

New PDPVerifier methods:

• getScheduledRemovals(dataSetId) - Returns array of piece IDs scheduled for removal

Benefits

1. Consumers can gain insight into piece removals by checking getScheduledRemovals

Open questions

• Is it acceptable to go around Curio like this or should we also post a message to Curio?
  • This was answered below. The answer is no.
• I regenerated the ABIs, but the diff is huge, it seems like this wasn't done in a while.. not sure of the standard process here but hoping to learn. Is there an ABI formatting tool we should run after, or are they knowingly out of date?

Related Issues

Closes filecoin-project/curio#808
Related filecoin-project/filecoin-pin#253
Also see this slack thread if you have access

[cloudflare-workers-and-pages]

Deploying with    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	c33240c	Commit Preview URL Branch Preview URL	Dec 02 2025, 02:13 PM

[rvagg]

I don't think this is what you want - for one, by asking Curio to do it, it gets to update its own internal view of the data set without having to be surprised later on that something happened on chain. It should be able to handle both cases but it's much cleaner to first try and request the server to do it for us (and it doesn't cost us gas, plus we can use session keys for this too so we get to be entirely walletless if we want).

The Curio handler actually does this immediately anyway, it doesn't do it in the background: https://github.com/filecoin-project/curio/blob/6814fede7b9612d12dff0899f4fa035ac1dde893/pdp/handlers.go#L889-L914 - the "schedule deletion" here is scheduling on chain.

The problem is, that in WarmStorage, we don't actually do anything with piecesScheduledRemove other than verify that it can be called by who called it: https://github.com/FilOzone/filecoin-services/blob/32e7dc5ef27625d7d343b661808e553414336996/service_contracts/src/FilecoinWarmStorageService.sol#L876-L901 - so we don't have any state to say that it's going to be removed at the next proving period (that's when we "schedule" it to be removed). So ... we never actually remove it from the WarmStorage state.

i.e. you've identified a hole in our contract flow where we don't properly follow up on deletions in WarmStorage even though we do in PDPVerifier. I'll open an issue in filecoin-services and link back to here. For now, you're just going to have to deal with the fact that the piece removal isn't visible via WarmStorage, or, you'll have to go fishing around in PDPVerifier to see what's there.

[rvagg]

My bad, I did more digging and reminded myself of the fact that we don't store per-piece information in WarmStorage anyway, and we use leafCount that we get in nextProvingPeriod to update our payment rates for the data set. We do have a clean-up problem as per FilOzone/filecoin-services#343 but it's not relevant to this issue.

The real problem you're experiencing in Filecoin Pin is this distance between the call to schedulePieceDeletions and when nextProvingPeriod is called. Because you get the piece list off PDPVerifier (with getPieces()) it's still going to show you the piece until the next proving period because it's not immediate.

What you should do instead, if you want this information, is to call getScheduledRemovals(uint256 setId) on PDPVerifier, then you know what will be deleted. Then when you're listing the pieces you could put a "(*pending removal)" note next to it. The data returned from that call will stay in sync with the piece list, it'll return nothing immediately after the next nextProvingPeriod call and the piece list will be trimmed.

[Kubuxu]

This won't work as is because pdpVerifier.schedulePieceDeletions() requires bilateral approval. So you would need signed extra data from Curio, which is not currently supported.

[SgtPooki]

So it sounds like the fix here to just remove the schedulePieceDeletions method on PDPVerifier and expose the getScheduledRemovals function, and call that in filecoin-pin.

I am presuming we don't want a blanket "getScheduledRemovals" parallel to getPieces, so i won't pipe it through inside synapse-sdk for now

[SgtPooki]

self review

[SgtPooki]

ok i tested this with some changes in filecoin-project/filecoin-pin#253 and there is still a delay, but it's working

┌  Filecoin Onchain Cloud Data Set Details for #48
│
◐  Fetching data set details..scheduledRemovals [ 8 ]
◇  ━━━ Data Set ━━━
│
│  Network: calibration
│  Client address: 0x2B3d0b827BAded638279C637d7ef21a266994c9E
│
│  #48
│    Status: live
│    CDN add-on: disabled
│
│    Provider
│      ID: 2
│      Address: 0xbCdf1bdc1a97D071a5a8EF03F1F05225b6E2a1Ba
│      Name: ezpdpz-calib2
│      Description: PDP Calibration node based in the UK
│      Service URL: https://calib2.ezpdpz.net
│      Active: yes
│      Location: C=GB;ST=Gloucestershire;L=Cheltenham
│
│    Metadata
│      source: "filecoin-pin"
│      withIPFSIndexing: ""
│
│    Payment
│      PDP rail ID: 89
│      Payer: 0x2B3d0b827BAded638279C637d7ef21a266994c9E
│      Payee: 0xbCdf1bdc1a97D071a5a8EF03F1F05225b6E2a1Ba
│
│    Pieces
│      Total pieces: 9
│      Total size: 1.6 KB
│      Unique PieceCIDs: 7
│      Unique IPFS Root CIDs: 7
│
│      #1 (active)
│        PieceCID: bafkzcibcdub2fsyawhoxetnwlwxajaqovmapo6b2tgkuw2uwhnjwdqfo2zt6wmq
│        Size: 225.0 B
│        Metadata
│          ipfsRootCID: "bafybeidifi6iaamwjrohdnsnumattjcraz6rm46mbfzpphkbtgnse2wd54"
│
│      #2 (active)
│        PieceCID: bafkzcibcdub3mf2pi3y523askafb774xgzz5rwma2qgjpi2tgacxevdozo2huja
│        Size: 225.0 B
│        Metadata
│          ipfsRootCID: "bafybeids6gixmju6uwwji332pa7mg2hej2ecojoqppa5let6whxvuw474u"
│
│      #3 (active)
│        PieceCID: bafkzcibcdubu56fv7yais7htphs3j6q6n53sl3osyrwsc45a6zuvv2amdj5qopi
│        Size: 225.0 B
│        Metadata
│          ipfsRootCID: "bafybeieltmtc5xuye5h4jfhjpyujrcloyll5fjdsuop4ulvx6raekxl6zy"
│
│      #4 (active)
│        PieceCID: bafkzcibcdubzlvmhmqgjksynuephe32tz7letfuct6o6ielczcsjkifrpfllobq
│        Size: 225.0 B
│        Metadata
│          ipfsRootCID: "bafybeig5utgrmrfqsvvhq42zopcxcf7cytcm4mpck6suaovlhzjt2hyxxu"
│
│      #5 (active)
│        PieceCID: bafkzcibcdubxifgdf7nmryydlkqbmo5q7a5r7wirrousepemrrkx55hb644awby
│        Size: 225.0 B
│        Metadata
│          ipfsRootCID: "bafybeidjstuje7huztr4mjwbqslwqkt4q4clypi76ijzzkwxvp5ngxzxra"
│
│      #6 (active)
│        PieceCID: bafkzcibcdubuavvokuyremde4qn5lh24rkscmx6onybphbhoeq6ijhwc2fdbcly
│        Size: 225.0 B
│        Metadata
│          ipfsRootCID: "bafybeig577ua2iyo2cyhciu4vcgotxbj3cxsjnmbhbkgzak24ruvtchbxq"
│
│      #8 (pending removal)
│        PieceCID: bafkzcibccab3ehc7kyk3a4btwhnkzuvohd4smkt7jqgwmecextou64dhve53key
│        Size: 238.0 B
│        Metadata
│          ipfsRootCID: "bafybeigbqiavfqi3ud2f7dqhqgrdipj7wgymr4hndfjcv7j5kljanmytny"
│
│
└  Data set inspection complete

[SgtPooki]

@hugomrdias @Kubuxu mind taking a peek when you get a chance? Fairly small changes here now.