Duplicate deeplinked rejection possible

[iamacook]

Description

When rejecting a deeplinked transaction as a singular owner, you complete the rejection transaction immediately and are then navigated to the on-chain rejection overview. However, on the on-chain rejection, it then asks for confirmation again, which has effectively already occured. By waiting for the next transaction list poll, the app will re-render and show that it has been indeed been executed.

We need to disable the execute/confirm possibility for single owners on on-chain rejection transactions that have already occured.

Note: The { type: 'Custom', isCancellation: true, ...txDetails } flags do not seem to be initially be accessible, perhaps because of the indexing speed (cc @jpalvarezl)?

Steps to reproduce

1. Queue a transaction on a Safe with one owner.
2. Reject the transaction and get create/get navigated to the on-chain rejection transaction.
3. Confirm button is visible and clickable

Expected result

Confirm button is not displayed and transaction shown as confirmed.

[jpalvarezl]

I think that is correct. We need the cancellation transaction to execute and be found by the services first, before we can flag the other transaction as cancelled.

[iamacook]

I guess we will have the use the Safe owners as the flag then.

[francovenica]

I have this problem creating and executing tx with 1 owner needed. They seem to be the same issue but if it is different from the reject one, let me know and I'll create a separated ticket.

The tx in the following gif is a dummy tx created with a test contract that works on rinkeby and has test methods (0x49d4450977E2c95362C13D3a31a09311E0Ea26A6)
The safe: https://pr2974--safereact.review-safe.gnosisdev.com/app/rin:0x6bb36b84abCb0Db1c8E2CAe68677D28DF73D99DF/transactions/queue

Check the gif: (1 min and 30 secs long, so patince)

[iamacook]

@francovenica, please see my comment on the actual issue. This is a known bug, which should not come to light with our initial disabling of the share button.