Repository navigation
Emit an event when pieces are scheduled for removal (schedulePieceDeletions) #281
Description
PDPVerifier.schedulePieceDeletions() marks pieces for removal and invokes the listener's piecesScheduledRemove callback, but emits no event. The FWSS callback is also silent: it charges the one-time fee, replenishes the lifecycle reserve, and queues metadata cleanup without emitting. A removal only becomes observable later, when PiecesRemoved fires during nextProvingPeriod processing.
It produces no log, so nothing log-driven sees it. Recovering a scheduled removal means reading contract storage, or scanning every transaction to the PDPVerifier address and decoding schedulePieceDeletions calldata. Neither is how event-driven indexers (foc-observer/Ponder, the PDP subgraph) work, so in practice the request is invisible to all of them until it's processed at the next proving boundary.
Proposed change
Emit an event in schedulePieceDeletions, mirroring the existing pattern:
event PiecesScheduledForRemoval(uint256 indexed setId, uint256[] pieceIds);PiecesRemoved still fires at processing time, so the pair gives a full request -> process timeline.
Activity
BigLep commentedon Jul 18, 2026
@rvagg : to make sure I'm following is the impact that our observability tools won't detect that a piece scheduled for deletion in proving period X until providing period X+1?
rvagg commentedon Jul 23, 2026
It's harder to detect but not impossible, you can look at the transactions and decode them, so it's not entirely lost; this is just a major QoL upgrade for observability. My point above is that everything we use today is event drive, not tx driven so we're not doing this and have no way to (easily) surface "X,Y,Z are scheduled for deletion at the next proving boundary"