We're currently relying on the fact of the protocol to avoid looking up deal proposals for the cached migration. Specifically, we assume that no deals could have been added between the pre-migration and migration that have already expired.
While this is true given how Lotus intends to use this migration, and given the protocol parameters for minimum deal duration today, it would be nice to avoid doing this by just looking up the proposal for any new deals. This isn't very fast, but there will likely be only a small number of such deals (about 10 hours worth), so we might as well do it for correctness.
We're currently relying on the fact of the protocol to avoid looking up deal proposals for the cached migration. Specifically, we assume that no deals could have been added between the pre-migration and migration that have already expired.
While this is true given how Lotus intends to use this migration, and given the protocol parameters for minimum deal duration today, it would be nice to avoid doing this by just looking up the proposal for any new deals. This isn't very fast, but there will likely be only a small number of such deals (about 10 hours worth), so we might as well do it for correctness.
Resolves this TODO: https://github.com/filecoin-project/go-state-types/blob/9c5492fe251234a0a8c3891938f235ea2b7381e7/builtin/v13/migration/market.go#L167