Check scenario: aggregator down, alloc closed, force redeem, remaining receipts

[aasseman]

The scenario is:

• At some point during the allocation lifetime, the sender aggregator goes down.
• We already have a RAV (but not last), and some unaggregated receipts
• The allocation is eventually closed
• The indexer forces a redeem on the RAV they got (mark the RAV as last, and let indexer-agent do the redeem)

So at some point, we have:

• The allocation is not "active" anymore according to the network subgraph eventual
• The RAV is marked as last && final
• We have remaining receipts for that allocation in DB

How will tap-agent behave at this point?

In particular:

• Will it continue tracking the unaggregated receipts?
• If the aggregator comes back, will it try to aggregate (we shouldn't do that with a last RAV that's potentially redeemed on-chain)

[tkornuta-semiotic]

The right question is: is there any chance that the Indexer will ever try to create a RAV request for "inactive" allocation...? @gusinacio

[aasseman]

The right question is: is there any chance that the Indexer will ever try to create a RAV request for "inactive" allocation...? @gusinacio

I'd maintain that the right questions are:

• Will it continue tracking the unaggregated receipts?
• If the aggregator comes back, will it try to aggregate (we shouldn't do that with a last RAV that's potentially redeemed on-chain)

[gusinacio]

The right question is: is there any chance that the Indexer will ever try to create a RAV request for "inactive" allocation...? @gusinacio

A closed allocation is already an "inactive" allocation and we do the last rav while closed.

[aasseman]

The right question is: is there any chance that the Indexer will ever try to create a RAV request for "inactive" allocation...? @gusinacio

A closed allocation is already an "inactive" allocation and we do the last rav while closed.

Yes but we're talking about the case where:

• the aggregator is down
• the indexer marked a RAV as last manually
• there are remaining receipts in the DB

[aasseman]

Test report

Events:

• An allocation was opened, received receipts, RAVs got generated.
• The aggregator was stopped.
• Eventually so many unaggregated fees accumulated that the sender got denylisted.
• The allocation was closed, a new one was created (by mistake).
• The RAV got manually marked as "last".
• Indexer agent picked it up almost immediately and successfully redeemed.
• The aggregator was brought back online.

At this point things got a bit weird:

• Because the old allocation is closed, it is marked as "blocked" in tap-agent so that the normal (unaggregated-fees trigger based) RAV request process is halted.
• Now we are in the 1hr wait period (after allocation close timestamp from the blockchain) before the tap-agent does the "last RAV" aggregation.
• We are stuck with the sender denylisted and no receipts on the new allocation.

tap-agent-1  |   2024-06-19T21:12:41.883459Z ERROR indexer_tap_agent::agent::sender_allocation: Error while requesting RAV for sender 0x21FEd3c4340f67DbF2b78c670ebD1940668CA03e and allocation 0xbed3CAeef28601cA60495ddEF6504D68E612C2ae: It looks like there are no valid receipts for the RAV request.This may happen if your `rav_request_trigger_value` is too low and no receipts were found outside the `rav_request_timestamp_buffer_ms`.You can fix this by increasing the `rav_request_trigger_value`.
tap-agent-1  |

tap-agent-1  |   2024-06-19T21:12:33.699983Z ERROR indexer_tap_agent::agent::sender_account: There was an error while requesting a RAV., error: Error while getting the heaviest allocation because no unblocked allocation has enough unaggregated fees tracked

Waiting to see what happens after the 1hr period expires...