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
Update transactions after /send command executed #4870
Conversation
branch PR-4870: |
72% of end-end tests have passed
Failed tests (8)Click to expand
Passed tests (21)Click to expand
|
@dmitryn I noticed that when you send a transaction then go offline and go back online when transaction is confirmed on etherscan (or on another device), the status is still "Pending". It stays like this until you visit Transaction History. Maybe we could update it when user goes online? Other things look good so far. |
@lukaszfryc added transactions update request when going back online. Please check. |
branch PR-4870: |
@dmitryn there is another issue in the recent build:
Since it's not a Beta blocker, I suggest going back to this PR after Beta is released. |
@lukaszfryc if TX is not in wallet, it deserves a separate issue as chat doesn't send transactions on its own, but uses wallet for that. |
2c59b8b
to
9334066
Compare
branch PR-4870: |
@dmitryn I still can reproduce the bug here. But, everything works fine on latest nightly ( |
@dmitryn What if the transaction stales for more than 90s? |
If user stay in the chat, nothing would happen after 90s. Next time we would update transactions if he goes to Wallet or goes offline -> online. |
@dmitryn here are TF logs for the missing incoming transaction issue:
|
@lukaszfryc thanks for providing TF sessions. After watching it, i noticed that device B (receiver) had changed network from mainnet to ropsten before receiving chat transaction. I could assume that device B doesn't see transaction because app pulls from wrong etherscan api ( |
branch PR-4870: |
branch PR-4870: |
@dmitryn I tested it again and the issue is still there. Here are more details: Device A: I sent ETH in 1:1 chat and went to transaction history to monitor the transaction. I waited for 10 minutes and transaction have still 0 confirmations in Status. When I opened it on etherscan, there was 16 confirmations. I refreshed the screen but there was still 0 confirmations. When I killed the app and logged in, the wallet showed correct amount (it included transaction) but the transaction history screen was empty. Device B: I received incoming transaction in chat but the status was "TX not found" and did not change. Wallet showed correct amount (included the transaction), but same as on Device A, the transaction history was empty. It worked the same when a transaction was made from Wallet. I have no idea how it's related to this PR and why everything works fine on latest nightly. @dmitryn I really need your help trying to investigate it. Maybe you could try again on your device? |
@lukaszfryc i haven't experienced this bug before. If transaction exists in blockchain and is shown on etherscan, it should also exist in transactions history in wallet (since wallet use etherscan API to fetch transactions history). I could assume that etherscan web UI and etherscan API may show different data for same account due to technical issues on their end (etherscan web and api use different data sources that could be out of sync, etc) The reason why wallet shows correct amount in your case is that we fetch balance data by web3 call (Infura API) so the data could be different from data provided by etherscan. |
@dmitryn the worst thing is that I can't replicate it on develop. It does not work only in this PR. I tried on different accounts including creating new ones. Are you sure it's working on your side? |
@lukaszfryc i still cannot reproduce this. If you think we should not merge this PR, we can close it and wait for #5138 as it will handle transactions update better. |
fixes #4865
Summary:
As a quick solution to issue described in #4865 we schedule 3 transaction state updates after funds got sent in chat – in 30, 60 and 90 seconds. These numbers are still experimental. Instead of 1 update 60 seconds later, we do 3 here – adds a bit of overhead, but brings faster feedback to the user and more confidence we get data from etherscan (additional request in 90 seconds).
status: ready