Closed dev-johnny-gh closed 8 months ago
There's no transaction hash because the underlying transaction needs to be wrapped into a Safe transaction and signed by owners. Only when it's fully signed do we have an actual hash. It happens asynchronously in most cases, so we cannot return a hash right away.
@katspaugh thanks for reply. i got what you mean, but i only have one signer, so i think we don't need to wait, at least gnosis can return the safe transaction hash or something i can identify this transaction later.
otherwise, how can i know the transaction is executed and get the transaction data from it?
@katspaugh another idea, can we keep the promise pending, until the transaction is signed by all signers, then return the transaction hash to the promise.
Yeah, I think the latter is doable, and it would resolve almost immediately in a 1/1 situation. 👍
@dasanra @mmv08 wdyt?
It was not walletconnect but ethers.js:
async sendTransaction(transaction: Deferrable<TransactionRequest>): Promise<TransactionResponse> {
// This cannot be mined any earlier than any recent block
const blockNumber = await this.provider._getInternalBlockNumber(100 + 2 * this.provider.pollingInterval);
// Send the transaction
const hash = await this.sendUncheckedTransaction(transaction);
try {
// Unfortunately, JSON-RPC only provides and opaque transaction hash
// for a response, and we need the actual transaction, so we poll
// for it; it should show up very quickly
return await poll(async () => {
const tx = await this.provider.getTransaction(hash);
if (tx === null) { return undefined; }
return this.provider._wrapTransaction(tx, hash, blockNumber);
}, { oncePoll: this.provider });
} catch (error) {
(<any>error).transactionHash = hash;
throw error;
}
}
They poll for the transaction receipt after sending, and since it's not an ethereum tx hash, it never resolves.
@mmv08 So, if I understand you correctly, I think the contract calls will use sendTransaction
function above, and this function will wait until the this.provider.getTransaction(hash)
can get the transaction. Otherwise, it will keep polling, right?
But gnosis returns the safe transaction hash, which can't retrieve an actual transaction on the chain, so my code is stuck.
So, how can I resolve this issue? I guess I can't use a workaround to prevent the ethers from using the sendTransaction
function on contract calls.
Can you return the transaction hash instead of the safe transaction hash?
Modifying the WalletConnect safe app to wait for all signatures to be given before resolving the promise seems like a reasonable solution. Mimicking what we do for EIP1271 signatures.
Can you return the transaction hash instead of the safe transaction hash?
We decided against this in the past because it is not guaranteed that the transaction will be executed and the ethereum transaction hash will be available. Also, with the safe transaction hash, you can use our backend to fetch transaction status and track the signing process. You're looking at this problem from a 1/1 safe user perspective, but there are much more sophisticated setups with 3+ geographically distributed signers.
Ideally, we'd like https://eips.ethereum.org/EIPS/eip-5792 to gain more adoption to fix this problem, as it's evident that the current Ethereum JSON-RPC API doesn't fit multisig wallet use cases.
What do you suggest in the meanwhile though, @mmv08? Dapps can issue transactions but they cannot detect it they went through or not.
Theoretically, we should support ether's .wait
method: https://github.com/safe-global/safe-react-apps/issues/377 I'd suggest checking why this stopped working
~The 1inch app is experiencing the same issue and it started a month or two ago. Might be some frontend change on our side?~
The 1inch is experiencing the same issue and it started a month or two ago. Might be some frontend change on our side?
they seem like different issues to me. In this one, the promise never resolves on the dapp side, and in the linked one, the wallet UI freezes
Theoretically, we should support ether's
.wait
method: #377 I'd suggest checking why this stopped working
I got feedback, our user said that he could use the gnosis with walletconnect before. So I switch back to the previous version of my dapp. but seems it's broken too. Just a heads up.
any update? @mmv08
I don't work on apps, so there are no updates from my side
@clemoon @dasanra could you prioritize this?
cc @katspaugh , will we overtake it and fix for the walletconnect native integration ?
Our native WalletConnect integration returns a tx hash for 1/X immediate executions.
Bug description
I use Walletconnect v2 to connect my dapp and gnosis web wallet.
After I call a contract function and send a transaction, I can't get the transaction hash from the transaction response. Actually, the promise is stuck and will never return.
The below code is part of my dapp code which is related to Walletconnect and the contract call. It can work when I use the im token wallet with Walletconnect, but it fails on the gnosis web wallet. Considering my code works on the im token, I suspect that there is something wrong with the gnosis web wallet. Can anyone help to find out what's wrong?
Also I check the wallet connect web socket and see these messages:
Environment
Expected result
the hash will be returned
Obtained result
the promise is stuck and will never return