`getActivePieces` runs out of gas with high offsets due to O(n) loop from index 0

[nijoe1]

Summary

The getActivePieces function becomes unusable at higher offsets because the loop always starts from i = 0, causing gas costs to scale linearly with offset.

Reproduction

Contract: 0xBADd0B92C1c71d02E7d520f64c0876538fa2557F

Dataset: setId = 64 (60,000+ pieces on Filecoin mainnet)

Call	Result
getActivePieces(64, 10000, 100)	✅ Works
getActivePieces(64, 12000, 100)	❌ OutOfGas

Root Cause

for (uint256 i = 0; i < maxPieceId; i++) {  // Always starts from 0
    if (pieceLeafCounts[setId][i] > 0) {
        if (activeCount >= offset && resultIndex < limit) {
            // collect
        }
        activeCount++;
    }
}

With offset 12,000, the function performs ~12,000+ cold storage reads just to reach the starting point.

Suggested Fix

Switch from offset-based to cursor-based pagination using startPieceId:

function getActivePieces(uint256 setId, uint256 startPieceId, uint256 limit)

Callers use the last returned pieceId as startPieceId for the next page, making pagination O(limit) instead of O(offset).

cc: @rvagg @BigLep @rjan90

[rvagg]

Wow, them's a lot of pieces. Good call-out on this. The original reason for the design here was because it's essentially a sparse array but a cursor-based approach would be fine too. We'd just need to introduce it as a new function rather than break the current one. getActivePiecesByCursor would probably be fine, with a startPieceId that points to the piece index that we can go directly to (but we may have to skip over if it's been deleted). Also an updated note in getActivePieces about why it might not be ideal for general use.

Not something we should hold GA up for, there are other ways to get this information (like a subgraph, or ask the SP), but this would be good to make available on chain next time we work through upgrades.

[Chaitu-Tatipamula]

Hey i'd like to pick this up, can you assign it to me?

[rvagg]

Done @Chaitu-Tatipamula