Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep the confirming transactions on the top of History #1500

Open
juanky201271 opened this issue Nov 5, 2024 · 2 comments
Open

Keep the confirming transactions on the top of History #1500

juanky201271 opened this issue Nov 5, 2024 · 2 comments
Assignees

Comments

@juanky201271
Copy link
Contributor

I noticed that when a transaction change from calculated to transmitted or from transmitted to mempool the date/time of the Value Transfer is the same... From the UX perspective would be really good if the date/time changed/updated as well...
This way the new (confirming) value transfers always are on the top of the list, and this is less confusing to the user.

@juanky201271
Copy link
Contributor Author

juanky201271 commented Dec 16, 2024

I'm working on Safe Communication and this problem is more obvious, because User 1 send a message to User 2 and User 2 reply with another message fast, and both are in the mempool... but the order is wrong attending the date of the transactions.

And if we want to do this properly, we need another stored date which is the moment when the tx enter in the mempool, because the actual date is when the tx is confirmed, and some txs take more time to confirm than others... and the Users see the messages in wrong order.

CC @Edicksonjga @zancas

@Edicksonjga
Copy link

Perhaps to avoid these problems you should wait for the transaction to be confirmed before enabling the Reply option, remember that a transaction in mempool does not guarantee that it will be confirmed.

It would be great to be able to reply quickly to each message to make it as close to instant messaging as possible, but taking into account the above, I think we should prevent the user from replying until there is a confirmation.

Still, I agree that the underlying bug reported above should be fixed. @juanky201271 @zancas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants