Skip to content
This repository was archived by the owner on Nov 10, 2023. It is now read-only.

Conversation

@DiogoSoaress
Copy link
Contributor

@DiogoSoaress DiogoSoaress commented Dec 10, 2021

What it solves

Resolves #3070 and #3071

How this PR fixes it

When adding queued transactions, it no longer mutates the current state, instead setting it to what backend returns. The "deeplinked" transaction details page persists the loaded transaction in state (if the automatic polling doesn't return queued transactions).

Client-side "PENDING"/PENDING_FAILED statuses have been moved to their own localStatuses key of the store, so as to not pollute the data returned from backend.

Note: the URL structure for deeplinked transactions has been reverted to using the safeTxHash, as follows:

.../app/{shortName}:{safeAddress}/transactions/{safeTxHash}

How to test it

Immediate transaction

  1. Create a transaction that executes immediately.
  2. Expect it to open the deeplinked transaction.
  3. Observe the pending spinner that eventually changed to success.
  4. After successful execution, check that it is only present in the history list.

Queued transaction

  1. Open a confirmed, deeplink transaction.
  2. Execute the transaction and expect points 3-4 above.

@github-actions
Copy link

CLA Assistant Lite All Contributors have signed the CLA.

@github-actions
Copy link

github-actions bot commented Dec 10, 2021

ESLint Summary View Full Report

Annotations are provided inline on the Files Changed tab. You can also see all annotations that were generated on the annotations page.

Type Occurrences Fixable
Errors 0 0
Warnings 0 0
Ignored 3 N/A
  • Result: ✅ success
  • Annotations: 0 total

Report generated by eslint-plus-action

@github-actions
Copy link

Deployment links

🟠 Safe Rinkeby Safe Mainnet 🟣 Safe Polygon 🟡 Safe BSC Safe Arbitrum 🟢 Safe xDai

@coveralls
Copy link

coveralls commented Dec 10, 2021

Pull Request Test Coverage Report for Build 1601361648

  • 13 of 132 (9.85%) changed or added relevant lines in 21 files are covered.
  • 14 unchanged lines in 9 files lost coverage.
  • Overall coverage increased (+0.03%) to 32.278%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/logic/safe/transactions/awaitingTransactions.ts 0 1 0.0%
src/logic/safe/utils/aboutToExecuteTx.ts 0 1 0.0%
src/routes/safe/components/Transactions/TxList/TxQueueRow.tsx 0 1 0.0%
src/routes/safe/components/Transactions/TxList/TxCollapsedActions.tsx 0 2 0.0%
src/logic/safe/store/reducer/localTransactions.ts 2 5 40.0%
src/routes/safe/components/Transactions/TxList/TxCollapsed.tsx 0 3 0.0%
src/routes/safe/components/Transactions/TxList/TxDetails.tsx 0 3 0.0%
src/routes/safe/components/Transactions/TxList/TxExpandedActions.tsx 1 4 25.0%
src/routes/safe/components/Transactions/TxList/hooks/useActionButtonsHandlers.ts 0 3 0.0%
src/logic/safe/store/actions/processTransaction.ts 0 4 0.0%
Files with Coverage Reduction New Missed Lines %
src/logic/safe/store/actions/createTransaction.ts 1 3.28%
src/logic/safe/store/middleware/notificationsMiddleware.ts 1 28.57%
src/routes/safe/components/Transactions/TxList/TxCollapsed.tsx 1 5.94%
src/routes/safe/components/Transactions/TxList/TxDetails.tsx 1 5.77%
src/routes/safe/components/Transactions/TxList/TxOwners.tsx 1 5.41%
src/routes/safe/components/Transactions/TxList/TxQueueCollapsed.tsx 1 8.7%
src/routes/safe/components/Transactions/TxList/TxSingularDetails.tsx 2 1.85%
src/logic/safe/store/actions/utils.ts 3 87.1%
src/logic/safe/store/reducer/gatewayTransactions.ts 3 2.3%
Totals Coverage Status
Change from base Build 1588198876: 0.03%
Covered Lines: 3083
Relevant Lines: 8488

💛 - Coveralls

@github-actions
Copy link

github-actions bot commented Dec 10, 2021

E2E Tests Passed ✅
Check the results here: https://github.com/gnosis/safe-react-e2e-tests/actions/runs/1601385671

Copy link
Contributor

@iamacook iamacook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. I found a few things and it seems the Polygon colour has been modified in the CGW.

@iamacook iamacook requested a review from katspaugh December 10, 2021 14:40
@iamacook iamacook marked this pull request as ready for review December 10, 2021 14:40
@iamacook
Copy link
Contributor

@DiogoSoaress, as this is your PR I cannot request your review. Please let me know what you think and "I" will approve it on your behalf.

Copy link
Member

@katspaugh katspaugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to see a massive chunk of code to be gone!

Copy link
Contributor

@iamacook iamacook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving after confirmation from @DiogoSoaress.

@DiogoSoaress
Copy link
Contributor Author

Looks good @iamacook 👍

@francovenica
Copy link
Contributor

francovenica commented Dec 14, 2021

Tx are shown only on the history tab. That works fine.

Still there are issues with the tx in the "Deep link view" that were not there before.
The tx reloads a couple of times while is executing and when it ends it shows a "cancelled" status.

@iamacook @DiogoSoaress is this re-rendering of the tx something we should worry about? or we can tackle it in another ticket?

Gif: is over 1 minute long
12-14-2021_x(3717)

@iamacook
Copy link
Contributor

iamacook commented Dec 15, 2021

is this re-rendering of the tx something we should worry about? or we can tackle it in another ticket?

As they are so tightly linked, I included the fixes for #3071 in this ticket (I will update the desc. when all is working). The remaining issue of the cancelled status I will include in this PR and, if it is too much of a rabbit hole, will open a separate issue for the re-rendering. I hope to include that in this PR however.

@iamacook iamacook marked this pull request as draft December 15, 2021 10:44
@iamacook iamacook linked an issue Dec 16, 2021 that may be closed by this pull request
@iamacook iamacook changed the title Duplicated tx in queued Inconsistent data on executing transactions, duplicated across queue/history Dec 16, 2021
// attaching ref to a div element as it was causing troubles to add a `ref` to a FunctionComponent
const txCollapsedStatus = (
<div className="tx-status" ref={sameString(lastItemId, transaction.id) ? ref : null}>
{transaction?.txStatus === 'PENDING' || transaction?.txStatus === 'PENDING_FAILED' ? (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno why it was also showing a loader for PENDING_FAILED. 🤷

@katspaugh katspaugh marked this pull request as ready for review December 16, 2021 17:52
@katspaugh katspaugh changed the title Inconsistent data on executing transactions, duplicated across queue/history Fix: deep-linked tx status and internal state Dec 16, 2021
Copy link
Contributor

@iamacook iamacook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of findings

@iamacook
Copy link
Contributor

When a transaction immediately executes, a notification is shown about confirmation still being required and no confirmations are shown in the owners stepper:

image

I'm pretty sure this is shown because the transaction passed to the reducer retains the 'stale' status and has an empty confirmations array. Maybe it does instead make more sense to keep the local status in the transaction object and, if it has a client-side "PENDING" status, fill the confirmations array with the current user?

The client-side statuses also never clear from the local state. They should likely be removed when the transaction is successful (both of the following are successful transactions):

image

}

const hasLocalStatus = transactions.some((tx) =>
localStatusedSafeTxHashes.some((safeTxHash) => tx.id.includes(safeTxHash)),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't tx.id different than safeTxHash? Or in this case it's same?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transaction summaries do not return the safeTxHash. The id, however, contains it.

Copy link
Member

@katspaugh katspaugh Dec 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it in a random place or can we extract the exact safeTxHash part and use it for a direct hash map lookup?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my understanding, it is the last part of the id but I am not 100% sure. It would be ideal if the safeTxHash was returned as part of the summary but that is something we'd have to discuss with backend in the new year.

break
}

const hasLocalStatus = transactions.some((tx) =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need to search the array or keys instead of just looking up the key in the hash map?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have the safeTxHash. Please check my other response.

@francovenica
Copy link
Contributor

francovenica commented Dec 21, 2021

Let me know if I can report these here or I should create new tickets.

If you create a tx out of nonce order you see the tx ready to be executed. The execute button should be disabled.
Only the execute button is wrong, the Reject button is fine to be available
To reproduce it, in a safe with a policy of 1 out of X create a tx 1 nonce higher than the one the safe expect to execute.

image

@iamacook
Copy link
Contributor

If you create a tx out of nonce order you see the tx ready to be executed. The execute button should be disabled. Only the execute button is wrong, the Reject button is fine to be available To reproduce it, in a safe with a policy of 1 out of X create a tx 1 nonce higher than the one the safe expect to execute.

This looks like a bug relating to non-owner execution of confirmed transactions. Can you confirm whether that was tested in that issue?

@francovenica
Copy link
Contributor

This looks like a bug relating to non-owner execution of confirmed transactions. Can you confirm whether that was tested in that issue?

I tested it in the #3151 and is not happening there. when a tx out of order is created the confirm button is disabled which is correct
image

@iamacook iamacook merged commit 8815f8b into dev Dec 21, 2021
@iamacook iamacook deleted the duplicated-tx-in-queued branch December 21, 2021 14:20
@github-actions github-actions bot locked and limited conversation to collaborators Dec 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Deep link - Inconsistent data while the a tx is being executed Deep link - Tx shown in history and queue tabs at the same time

6 participants