-
Notifications
You must be signed in to change notification settings - Fork 360
Fix: deep-linked tx status and internal state #3156
Conversation
|
CLA Assistant Lite All Contributors have signed the CLA. |
ESLint Summary View Full Report
Report generated by eslint-plus-action |
Deployment links
|
|
E2E Tests Passed ✅ |
iamacook
left a comment
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.
Looking good. I found a few things and it seems the Polygon colour has been modified in the CGW.
|
@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. |
katspaugh
left a comment
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.
Good to see a massive chunk of code to be gone!
iamacook
left a comment
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.
Approving after confirmation from @DiogoSoaress.
|
Looks good @iamacook 👍 |
|
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. @iamacook @DiogoSoaress 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. |
| // 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' ? ( |
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.
Dunno why it was also showing a loader for PENDING_FAILED. 🤷
iamacook
left a comment
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.
Just a couple of findings
|
When a transaction immediately executes, a notification is shown about confirmation still being required and no confirmations are shown in the owners stepper: I'm pretty sure this is shown because the transaction passed to the reducer retains the 'stale' status and has an empty 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): |
| } | ||
|
|
||
| const hasLocalStatus = transactions.some((tx) => | ||
| localStatusedSafeTxHashes.some((safeTxHash) => tx.id.includes(safeTxHash)), |
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.
Isn't tx.id different than safeTxHash? Or in this case it's same?
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.
Transaction summaries do not return the safeTxHash. The id, however, contains it.
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.
Is it in a random place or can we extract the exact safeTxHash part and use it for a direct hash map lookup?
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.
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) => |
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.
Why do you need to search the array or keys instead of just looking up the key in the hash map?
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.
We don't have the safeTxHash. Please check my other response.
|
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. |
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 |





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_FAILEDstatuses have been moved to their ownlocalStatuseskey 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:How to test it
Immediate transaction
Queued transaction