`getPdpDataSet` fails on large data sets because `getActivePieceCount` reverts inside multicall

[BravoNatalie]

Description

getPdpDataSet() can fail for large live datasets even when all of its underlying reads are valid. The issue is that getActivePieceCount(setId) iterates through every piece ID from 0 to nextPieceId[setId], so the cost of the call grows with the total piece ID range. For large datasets, this subcall can exceed the limits and revert inside Multicall3, causing the entire getPdpDataSet() call to fail.

This can be reproduced on Filecoin mainnet with setId = 1273. All of the underlying reads succeed when called individually, including getDataSet, dataSetLive, getDataSetListener, getAllDataSetMetadata, getPDPProvider, and getActivePieceCount. However, getPdpDataSet() fails because it executes all of these reads through a single multicall. In that context, the getActivePieceCount(setId) subcall becomes too expensive and reverts, causing the entire getPdpDataSet() call to fail.

Proposed solution

Make getPdpDataSet() reliable for large datasets by removing getActivePieceCount from the readPdpDataSetInfo multicall. getPdpDataSet() can fetch activePieceCount separately, derive it using getActivePiecesByCursor (which is guaranteed to scale to large datasets), or omit the piece count entirely.

Also add documentation recommending getActivePiecesByCursor as a fallback for callers that explicitly need a derived active piece count.

Done criteria

• getPdpDataSet(setId) succeeds for large live data sets where the current implementation fails

Notes

• Related issue getActivePieceCount fails with out-of-gas for large datasets pdp#265

[TippyFlitsUK]

Adding a mainnet report of the same revert reached through a different entry point.

Report: flagless filecoin-pin add (716 KiB file) fails for a wallet owning data set 1344 (~341k active pieces on-chain):

◇  ✗ Add failed: The contract function "getActivePieceCount" reverted.

Contract Call:
  address:   0xBADd0B92C1c71d02E7d520f64c0876538fa2557F
  function:  getActivePieceCount(uint256 setId)
  args:                         (1344)

Where it happens: in this case the revert occurs during default provider selection, before any data set has been chosen for the upload: createContexts() with no selectors → smartSelect → fetchProviderSelectionInput → getPdpDataSets → readPdpDataSetInfo, whose multicall includes getActivePieceCountCall per data set with allowFailure: false. Because selection enumerates every data set the client owns, a wallet holding one large data set hits the revert on every flagless add, regardless of which data set the upload would target and regardless of upload size. Noting this because the description frames the failure around getPdpDataSet() callers; the same multicall is also reached via this default selection path.

Workaround we're using: pointing the upload at the data set explicitly, i.e. filecoin-pin add <file> --data-set-id <id>. From a code read of current main, that path (resolveByDataSetId) reads getDataSet + getDataSetMetadata + validateDataSet only and does not call getActivePieceCount, so it avoids the revert. For reference, --provider-id also avoided it in our read (resolveByProviderId checks pieces via getActivePieces with a limit of 1 rather than getActivePieceCount).

Happy to share more detail from the affected setup if useful.