"Cancelled" status when a tx is executing

[francovenica]

Update

From @iamacook: It is not confirmed whether backend will issue a true fix for this.

We have discussed a way of getting around this as it seems to be occurring more and more often. @katspaugh hypothesised implementing a default timeout of ca. 15s by default to set a transaction as pending, regardless of it's 'true' status. It would be good to discuss this upon estimation and decide whether we implement this 'fix' on our end.

Description

in non-rinkeby safes, with a 1 out of x policy, when a tx is being executed, instead of the "pending" status it shows a cancelled status. This status also shows in the history tab for a while until it "fixes itself"

Environment

• Browser: chrome
• Wallet: MetaMask
• Safe:
• Environment:
  Release 3.17.0 #3260 xdai, avalanche, polygon

Steps to reproduce

in non-rinkeby networks ( L2 networks)

1. Go to a safe of 1 out of X

2. Create and execute a tx right away
   Current result: Tx is opened as deeplink with "Transaction executed successfully" message and status "Cancelled"
   Shows cancelled status in the history tab as well for a few minutes

3. Check propose request:
   Current result: Cancelled status is returned by CGW

4. wait for some time to see the updated state
   Current result: The user has to do a manual refresh to see the correct state

Expected result

1. Success state if the tx was created and executed successfully to align with the success message
2. Is it possible to update the "cancelled" state automatically if no possibility to show a success state right away without manual refresh from the user side?

Screenshots

[francovenica]

Not happening anymore, probably backend issues. Closing

[iamacook]

I will close this as we established the problem stems from backend (please see the issue linked above).

[JagoFigueroa]

Hola guys, I have been able to reproduce this in the desktop app as well. Probably a backend issue as you say but I think it would be nice if we could push for a fix.

Not pretty to have successful transactions with cancelled status :(

[iamacook]

Hola guys, I have been able to reproduce this in the desktop app as well. Probably a backend issue as you say but I think it would be nice if we could push for a fix.

We are aware of this and are actively thinking of a solution. It is a backend issue, and they have an open issue regarding it.

[liliya-soroka]

Could we do some auto-update as soon as the state is updated on CGW ?

[iamacook]

Could we do some auto-update as soon as the state is updated on CGW ?

We would have to continuously poll to ascertain if the status changes on the CGW side which requires far to many requests. I think the proposal to pend by default for 15s makes the most sense given the current situation.

[jpalvarezl]

After the backend sync meeting with @katspaugh , we thought what you propose, @iamacook , having a 15s pending state would be a good way to tackle this issue. Also, once you are able to leverage notifications in the web app too (this is related to the research topic), this issue should be solved completely.

[iamacook]

I'm closing this as the local pending statuses now takes precedence over that from the backend. We now have a dedicated pendingTransactions store entry in which we store transaction IDs.