Status-react: No message received in 1-1, group chat by the contact which is online after ~10 minutes of being offline
Type: Bug
Summary: No message (text/emoji, /request, /location, /send) received by the contact in 1-1, group chat when a message is sent to the contact which appears online after been ~10 minutes offline, until the contact re-log in into account.
Please note, messages have been sent to user when he is online.
The key of this case is: to go offline for 10 minutes and get back online without restarting the app.
Expected behavior
When I send a message to contact which is online now (but it was offline for 10 minutes or more before), - this contact receives message fine.
Actual behavior
When I send a message to contact which is online now (but it was offline for 10 minutes or more before), - this contact won't receive this message (until he re-login into account).
Reproduction
1) Open Status on Device1 and create account
2) Open Status on Device2 and create account
3) Device1 adds Device2 in contacts
4) Device1 sends message to Device2 and vice versa. Confirm both messages appears on both devices, with 'Delivered' statuses.
5) Turn Airplane mode ON on Device1
6) Wait >= 10 minutes
7) Turn Airplane mode OFF on Device1. Navigate to 1-1 chat you had before with Device2.
8) Device2 sends text message to Device1.
Actual result: No message received on Device1 side.
Additional Information 1
It was noticed that if to proceed above scenario with one more step:
9) Device1 sends text message to Device2.
Actual result: Message appeared on Device2 side, however, there is no 'Delivered' status on Device1 side for this message.
Additional Information 2
If in the 6th step above to stay in Offline mode for 2-3 minutes - everything will be fine with further messaging between both contacts.
Additional Information 3
Transactions are sent and received fine in that case.
Additional Information 4
- Status version: Develop 0.9.11d600, (also reproduced in latest Develop (22nd of Jan) with 'Offline Inbox' OFF), Release 0.9.13+ (19th of January)
- Operating System: Android 7.0, Android 6.0, iOS 11.2.1
TF session representing device1 (after 10 minutes it was in offline - so from 7th step in reproduction steps above): https://app.testfairy.com/projects/4803590-status/builds/7549901/sessions/28/?accessToken=JG8aPNFDnrenko-rzf-QvsgFnX8
TF session representing device2 (after 10 minutes Device2 was in offline) - from 09:48: https://app.testfairy.com/projects/4803622-status/builds/7534654/sessions/60/?accessToken=tMUthBlmxQzJfiVOdk4YjhfRA9M
Serhy
All 17 comments
I wonder if this is related to the log entries we're seeing in https://github.com/status-im/status-react/issues/3096, which also happens after similar conditions are met.
pedropombeiro
on 6 Feb 2018
Current balance: 0.000000 ETH
Contract address: 0x95f27acdaf1a6d730f8e2c4f6b8c284f0afc8d3e
Network: Mainnet
To claim this bounty sign up at https://openbounty.status.im and make sure to update your Ethereum address in My Payment Details so that the bounty is correctly allocated.
To fund it, send ETH or ERC20/ERC223 tokens to the contract address.
status-open-bounty
on 6 Feb 2018
I wonder if this is related to the log entries we're seeing in #3096, which also happens after similar conditions are met.
@PombeirP yes, you can find same log errors in TF session for device1.
dmitryn
on 6 Feb 2018
OK, just so we remember to close that one once this is fixed. Oh, it's been done already, good!
pedropombeiro
on 6 Feb 2018
Just found this issue linked to another one that I was investigating. Application needs to re-create a filter if it wasn't used for longer than 300s. Please see https://github.com/ethereum/go-ethereum/blob/master/whisper/whisperv5/api.go#L76-L82 . That is by whisper design, used to prevent leaks of not used filters. The only thing we can do is to increase this "idle" timeout, but I doubt that it will make any meaningful change.
GitHub
go-ethereum - Official Go implementation of the Ethereum protocol
dshulyak
on 10 Feb 2018
Also, it probably means that if app goes to sleep then all messages received by the geth node during that time won't be received by the app itself (because a filter is removed after 300s). Seems like a big issue to me).
We can disable that "cleaner", because we have only one filters consumer, and rely on status-react to always remove not used filters.
dshulyak
on 10 Feb 2018
@dshulyak great find! I can confirm that it makes a difference, having created an Android build with the run() method commented out, I can keep on receiving new messages even after having left my phone alone for more than 10 minutes!
pedropombeiro
on 10 Feb 2018
One important thing I want to point out, that status-go actually returned this error (filter not found).
I think we need to at least show some message if any of the web3 APIs returns an error. That would greatly simplify any debugging.
mandrigin
on 10 Feb 2018
@dshulyak @PombeirP great! we can quickfix it with a patch. After that, it would be nice to upstream something that optionally disables this "garbage collection" because it isn't really compatible with any mobile use-case.
Btw, Whisper V6, does it also have this behaviour?
mandrigin
on 10 Feb 2018
@mandrigin yeah, that was also my hope, but unfortunately the code stayed the same there.
pedropombeiro
on 10 Feb 2018
Actually, there is an even better way to handle this without disabling a "cleaner". Whisper API provides subscription available on shh_messages, this subscription will create and poll filter internally every 250 ms. This way status-react doesn't have to poll shh_getFilterMessages in the foreground, and filter will be always open until the subscription will be explicitly closed.
Is there any reason why shh_messages cannot be used? https://web3js.readthedocs.io/en/1.0/web3-shh.html#subscribe
dshulyak
on 11 Feb 2018
If we update status-go to the latest develop, it should be fixed.
→ https://github.com/status-im/status-react/pull/3236 is the current update PR
mandrigin
on 12 Feb 2018
It would be great to have some insight from the status-react side because something is off. I believe it works this way:
- When creating a filter to get messages through web3.js, a subscriber is returned which polls for messages (it's internal web3.js poller),
- The app goes into background/airplane mode and is inactive for over 10 minutes,
- The app goes foreground, status-go cleans up old filters that were unused for 10 minutes,
- web3.js resumes its polling...? If so, it should throw an error as the filter it tries to use does not exist anymore.
adambabik
on 12 Feb 2018
It does resume and prints messages in the logs, but it seems like the log level is off. And the polling continues.
mandrigin
on 12 Feb 2018
But how can it continue if the filter is gone? Unless this code is executed: https://github.com/ethereum/web3.js/blob/62dd77c7f43522eb568a001cf4c4df726f8efa69/lib/web3/requestmanager.js#L234-L236 which simply ignores any error...
web3.js - Ethereum JavaScript API
adambabik
on 12 Feb 2018
My debugger in Xcode tells me that the web3 methods are still being called. I didn't dive deep into the client-side code to figure out why.
I 100% agree with you that we need to investigate. Otherwise, it would be very hard to debug similar issues.
mandrigin
on 12 Feb 2018
Closed by https://github.com/status-im/status-react/pull/3291 and https://github.com/status-im/status-go/pull/650
mandrigin
on 20 Feb 2018
Related issues
errorists
·
3Comments
mfekadu
·
3Comments
denis-sharypin
·
4Comments
annadanchenko
·
3Comments
andytudhope
·
4Comments
Most helpful comment
Just found this issue linked to another one that I was investigating. Application needs to re-create a filter if it wasn't used for longer than 300s. Please see https://github.com/ethereum/go-ethereum/blob/master/whisper/whisperv5/api.go#L76-L82 . That is by whisper design, used to prevent leaks of not used filters. The only thing we can do is to increase this "idle" timeout, but I doubt that it will make any meaningful change.