Reversible Transfer Events
This document outlines how to track the lifecycle of a reversible transfer by correlating events from the reversible-transfers, scheduler, and balances pallets.
When a reversible transfer is executed by the scheduler pallet, the final balances::Transfer event does not have a direct identifier linking it back to the initial transaction. This makes it challenging to trace, especially if multiple identical transfers are processed in the same block.
The key to tracking the entire lifecycle is to use the tx_id from the reversible-transfers pallet and the deterministic order of events emitted during execution.
When a reversible transfer is scheduled, the reversible-transfers pallet generates a unique tx_id. This tx_id is then used as the schedule_id (specifically, a TaskName) when the task is registered with the scheduler pallet.
When the scheduler executes the transfer, a specific sequence of events is guaranteed to be emitted in the following order:
-
scheduler::Dispatched: This event marks the beginning of the execution. It contains anidfield which is theTaskNamecorresponding to the reversible transfer'stx_id. -
balances::Transfer: This event is emitted immediately after thescheduler::Dispatchedevent. It represents the actual transfer of funds but lacks a direct ID. You can reliably link it to the dispatched task because it will be the very next event in the block. -
reversible-transfers::TransactionExecuted: This event is emitted last in the sequence, confirming that the reversible transfer logic has been successfully executed. It also contains the originaltx_id, which provides a final confirmation that you are tracking the correct transaction.
By relying on this guaranteed order, you can confidently correlate all three events, even in complex scenarios with multiple identical transfers.
The following diagram illustrates the complete, ordered flow of events:
