-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reject failed transactions in TransactionProcessor #22
Conversation
…ue to program error
); | ||
let results: PromiseSettledResult<string>[] = []; | ||
const confirmTx = async (txId: string) => { | ||
const result = await this.connection.confirmTransaction({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this PR is simpler than before, because web3.js itself now supports proper transaction confrimation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for documentation - unseen in this change is our under the hood upgrade of web3.js.
relevant PR to upgrade confirmation logic is released on v1.42.0. We previously upgraded to 1.43.1
solana-labs/solana#25227
blockhash, | ||
}); | ||
|
||
if (result.value.err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note that our transaction confirmation promise now rejects if the program fails (e.g. slippage failure). this is different from the previous behavior, where the promise did not reject, and we showed the "Transaction succeeded" snackbar
imo, this new implementation is not ideal. the ideal is that the function immediately returns the txid after sending the transaction but before confirming the transaction. this allows the UI to show a pending snackbar. afterwards, the txid should be used to separately confirm the transaction
however, this would require a deeper change in TransactionProcessor
, which i think we can reserve for our future refactor
// of the implications of the resigning - could be quite annoying from a user perspective | ||
// if their wallet forces them to sign for each | ||
results.push(await promiseToSettled(txPromise)); | ||
const results = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the old implementation didn't actually send the transactions serially when parallel=false
. it only confirmed the transactions serially
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
patch lgtm.
It feels like with the web3 upgrade the responsibilities of TransactionProcessor is reduced to a promise handler for a group of transaction. Maybe we can drop this class and migrate it's responsibility to the future transaction packer down the road.
); | ||
let results: PromiseSettledResult<string>[] = []; | ||
const confirmTx = async (txId: string) => { | ||
const result = await this.connection.confirmTransaction({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for documentation - unseen in this change is our under the hood upgrade of web3.js.
relevant PR to upgrade confirmation logic is released on v1.42.0. We previously upgraded to 1.43.1
solana-labs/solana#25227
…)"" This reverts commit 3d008ce.
No description provided.