feat(subgraph): sample pieces that entered service termination grace period

[dennis-tra]

The sampled retrieval process queries pieces that are marked as isActive: true. This excludes pieces that have been terminated but technically may still be served by the SP. See this comment from @silent-cipher:

One caveat though: the rail isn't always terminated immediately after terminateService. In some cases it remains active for up to 30 days after the terminateService call. By relying solely on isActive, we'd also exclude pieces that are still technically available during that grace period.

This issue is here to capture work to also query pieces that have entered the grace period.

One approach to fix this is:

If we ever want to account for that, I think it's straightforward to fix. In the handler we already know the current block/timestamp and the pdpEndEpoch, so we can compute the timestamp at which the PDP rail actually terminates, store that on the dataset, and have the sampling query filter based on that timestamp instead of isActive.

Note: this would require a reindex of the subgraph.

Opinion

With the sampled retrieval we want to make sure to check SPs to behave well for non-dealbot pieces. Arguably, pieces entering a grace period make them a very sensible target to check. At the same time I believe they would make up the minority of the available pieces and thus have a very little chance of being selected anyways given our current random draw logic.

References

• feat: anon piece selection and retrieval #487 (comment)
• feat(subgraph): mark pieces as inactive when the pdpPaymentEndEpoch has passed #579
• feat(subgraph): track payment-active state for cheaper anon-retrieval queries #582
• refactor(retrieval-anon): filter expired PDP payments at the subgraph probe-lab/dealbot#12

[BigLep]

The issue makes sense. That said, I don't think there is a lot of user value in taking on this extra effort for now. I'm good on deferring this indefinitely at this point.

[BigLep]

@dennis-tra : one action though that I think we should take is to make sure that the "rules of the game" (https://github.com/FilOzone/dealbot/blob/main/docs/checks/sampled-retrievals.md) are accurate. We can denote the caveat and point to this issue.