Conversation
| bytes32 indexed id, | ||
| address indexed subscriber, | ||
| address indexed recipient, | ||
| uint256 lastRedeemed, |
There was a problem hiding this comment.
I think we actually want to have nextRedeemAt here. Otherwise the indexer will have to compute next redeem.
See here:
There was a problem hiding this comment.
True, except the current sub.lastRedeemed is equivalent to nextRedeemAt. It gets updated in _applyRedemption. It's also important that, when there are multiple periods being potentially redeemed, it is incremented by (number periods x frequency) & not via block.timestamp.
Correct me if I'm wrong though.
There was a problem hiding this comment.
I think renaming the current lastRedeemed param to nextRedeemAt makes sense, but keep how it's currently being used/set.
There was a problem hiding this comment.
I saw that last redeemed was timestamp minus frequency. But next redeem at is timestamp plus frequency. I guess it's also ok to leave this, and the sql query could be adjusted to add the two fields together.
|
Closing. Added in group subscription overhaul, see #16. |
2 participants
Closes #17