[nishant-uxs]

Summary

• Emit PiecesScheduledForRemoval(setId, pieceIds) from schedulePieceDeletions so indexers can observe scheduled removals immediately, without waiting for PiecesRemoved at the next proving boundary.
• Declare the event in IPDPEvents alongside the existing piece lifecycle events.

Closes #281

Files Changed

• src/interfaces/IPDPEvents.sol
• src/PDPVerifier.sol
• test/PDPVerifier.t.sol

Testing Performed

• forge build --via-ir
• forge test --via-ir (187 passed)

Known Limitations

• Does not change listener/piecesScheduledRemove behavior; event is for log-driven consumers.

Risk Assessment

• Low: additive event only; no storage layout or ABI-breaking logic changes beyond a new event topic.

[wjmelements]

emit after listener instead of before, in case listener rejects

[nishant-uxs]

Addressed in 8aba46b — emit now happens after the listener call, matching the other listener/emit sequences in PDPVerifier (e.g. _createDataSet, deleteDataSet, nextProvingPeriod), so a rejecting listener reverts before the event is recorded.

[rvagg]

thanks @nishant-uxs, this is going to need an abi update, make update-abi should do it

[nishant-uxs]

Thanks @rvagg — addressed.

make update-abi lives in FilOzone/filecoin-services (not this repo), so I opened a companion draft PR that adds PiecesScheduledForRemoval to the checked-in PDPVerifier ABI:

FilOzone/filecoin-services#566

Once this PR merges, we can bump service_contracts/lib/pdp to the merge commit and re-run make -C service_contracts update-abi so check-abi matches source.

[Kubuxu]

This PR limits the number of scheduled pieces per transaction to about ~254 due to the 8KiB event size limit.
As far as I can see, this hasn't landed in a release, so we can remediate.
We could emit event PiecesScheduledForRemoval(uint256 indexed setId, uint64[] pieceIds);, which would bump it to ~511, or we could split the event at some boundary to keep the size in check.
With #283, we can allow for larger removals.

I detected this while running a benchmark sweep.

[rvagg]

👍 my preference would be to do it in chunks, at some boundary like 100, but doing it by ID I guess could be fine too since indexers would have the original mapping of cid to id; or at least they'll have to

[wjmelements]

uint64[] pieceIds

These are still 32 bytes in solidity.

[Kubuxu]

These are still 32 bytes in solidity.

You are right, interesting that that is the definition of alignment rules.