TransactionWorker to fire events a dapp can listen to

[0xmaayan]

Description

The transaction management is a send-and-forget process in a way that once transactions are sent to worker, the dapp is not aware of what is going on unless a potential error happens.

This PR adds logic for the TransactionWorker module to fire events during a worker task and dapp can listen to these events.

aptos.transaction.batch.on(TransactionWorkerEvents.ExecutionFinish, async (data) => {
   console.log("execution finish", data);
});

Note:
Currently, dapp uses aptos.batchTransactionsForSingleAccount() to start the worker. We now introduce a dedicated namespace under aptos.transaction.batch where one can use aptos.transaction.batch.forSingleAccount() same as before. This is for potential future enhancement of the worker and to conform with the sdk design.

Test Plan

pnpm test
batch_mint and batch_funds for examples

Related Links

[banool]

Unless it's really expense to emit events it might not be worth the complexity.

[banool]

Is this the data being emitted? If so, shouldn't we emit something structured instead? That way the callback can actually do something with the data. So it emits some kind of TransactionSentEventData that has a txnHash field. The user can use that type in the callback too rather than data: any.

[0xmaayan]

Good call! I have updated the worker/management to have a types returned data

[kaw2k]

Ok, just double checking I understand each event:

• transactionSent is fired after a transaction gets sent to the chain
• transactionSendFailed is fired if there is an error sending the transaction to the chain
• transactionExecuted is fired when a single transaction has run successfully
• transactionExecutionFailed is run if a single transaction fails in execution
• executionFinish is run when the queue has been emptied

So if someone wanted to make an async function to batch requests, it would look like this:

// Pseudo code
type TxnHash = string;
function batchTransactionExample(sender: Account, payload: InputGenerateTransactionPayloadData[]): Promise<{
	succeeded_txns: TxnHash[],
	failed_txns: TxnHash[]
}> {
	return new Promise(async (resolve, reject) => {
		let succeeded_txns = [];
		let failed_txns = [];
		
		aptos.transaction.batch.forSingleAccount({sender, data: payload})

		// Handle transaction successes, we don't care about sent, just executed
		aptos.transaction.batch.on(TransactionWorkerEvents.TransactionExecuted, async (data: any) => {
			succeeded_txns.push(data.txn_hash);
		});

		// Handle transaction failures (execution or send)
		aptos.transaction.batch.on(TransactionWorkerEvents.TransactionExecutionFailed, async (data: any) => {
			failed_txns.push(data.txn_hash);
		});
		aptos.transaction.batch.on(TransactionWorkerEvents.TransactionSendFailed, async (data: any) => {
			failed_txns.push(data.txn_hash);
		});

		// Handle resolving the promise
		aptos.transaction.batch.on(TransactionWorkerEvents.ExecutionFinish, async (data: any) => {
			resolve({ succeeded_txns, failed_txns })
		});
	})
}

I'm guessing the caller will have to unsubscribe from the emitter? That is something we would want to highlight in the two examples potentially.

[0xmaayan]

yep! I'll add some doc comments - good catch!

[kaw2k]

❤️

[kaw2k]

Thanks for getting this in!!!