You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ideally the refund is executed automatically...
There are several ways to do this but perhaps it will be a good time for off-chain workers to shine? since we might be iterating and filtering the potentially big list of payments I think it's something we can delegate to a worker, we might also want to keep track separately of payments in the RefundRequested state for simpler processing
Another approach that is simpler than off-chain workers and elegant enough is to do like the scheduler pallet that has an Agenda which is a storage item that indexes the tasks(e.g. Task::Refund(from, to)) by block number so the on_initialize hook can check for each block if there's anything to be done. Can also be used for #8
on_idle sounds reasonable, maybe not for the recurrent payment indexed by block number but here could work, we keep a "queue" of pending refunds and try to refund as many as possible with the remaining weight of the idle block
ideally the refund is executed automatically...
There are several ways to do this but perhaps it will be a good time for off-chain workers to shine? since we might be iterating and filtering the potentially big list of payments I think it's something we can delegate to a worker, we might also want to keep track separately of payments in the
RefundRequested
state for simpler processingOriginally posted by @olanod in virto-network/kreivo#186 (review)
The text was updated successfully, but these errors were encountered: