Light Push and Filter eventually stop working

[felicio]

What

Note: Recovery of the messages during periods of disconnect is not the main subject of this issue

>Note: Sufficient workaround for Relay at https://github.com/status-im/status-web/pull/288/files

1. Build project
2. Serve /dist
3. Visit URL
4. Set debug to * in Local Storage
5. Reload
6. Send messages before, during and after going Offline in Network > No throttling > Offline
7. Send messages after (several hours) waking computer from sleeping
8. See Light Push delivering messages but not "self emitting" to our UI
9. See Filter no longer receiving messages
10. See wakuDisconnectionTimer interval no longer being fired

See errors (in order) during which messaging is not working:

1. WebSocket connection to 'wss://node-01.do-ams3.status.test.statusim.net/p2p/16Uiu2HAkukebeXjTQ9QDBeNDWuGfbaSg79wkkhK4vPocLgR6QFDf' failed:
2. Uncaught (in promise) Error: Muxer already closed

See debug logs.

How

• Either programmatically reload page
• Ping Filter protocol subscriptions with a Waku message and re-subscribe if not delivered
• Automatically resubscribe on reconnect
• Else

---

Related

• https://github.com/waku-org/js-waku/issues/751
• https://github.com/libp2p/js-libp2p/issues/939
• https://github.com/libp2p/js-libp2p/issues/744
• https://github.com/xmtp/xmtp-js/pull/128
• https://github.com/xmtp/go-waku/pull/29
• https://github.com/vacp2p/rfc/issues/469
• https://github.com/vacp2p/rfc/pull/562
• https://github.com/waku-org/pm/issues/5

[felicio]

Notes

• Identify broken streams (with pings)
• Recover stream (let libp2p handle it automatically on directly closing the connection)
• Identify broken connection (with pings, libp2p event)
• Recover broken connection (no retry strategy yet, only letting UI know and stopping the client)
• Identify loss of internet (with browser event)
• Identify dropped filter subscriptions (not implemented yet; as a workaround send a custom ping message and if not received, resubscribe)
• Track gap time ranges (not implemented yet)
• Fetch gaps on recover (not implemented yet)

[felicio]

Notes

10. See wakuDisconnectionTimer interval no longer being fired

So it looks like Chrome suspends or at least slows down javascript execution in a tab that has no focus. Couldn't find much on the internet on the subject. It would mean that we can't run background tasks, like for example checking periodically on a server using XHR calls and setInterval (I suspect to see the same behavior for setInterval, will write a test if time is with me). – https://stackoverflow.com/questions/6032429/chrome-timeouts-interval-suspended-in-background-tabs

When I go to another tab and come back after a while, all divs transition at the same time and the setTimeOut is completely ignored. – https://stackoverflow.com/questions/6032429/chrome-timeouts-interval-suspended-in-background-tabs#comment47225370_6032429

TL;DR: use Web Workers.

There is a solution to use Web Workers, because they run in separate process and are not slowed down

"Update, Jan 2021 : From Chrome 88+, timers can be throttled to 1 minute in certain conditions. Read more usefulangle.com/web-updates/post/110/…"

The Chromium insider also clarified that aggressive throttling will be automatically disabled for all background tabs “playing audio” as well as for any page where an “active websocket connection is present.”

I tested running setInterval on Chrome 100 with 1 minute interval and locked the screen. The function had been executed in roughly 30-180 second intervals.

[felicio]

Relates to https://github.com/waku-org/js-waku/issues/1189