Light-client: Raiden stops suddenly

[christianbrb]

Thanks for filing a bug report :-)

Steps to Reproduce

1. Use the dApp
2. Keep it unattended

Expected Result

• dApp is running

Actual Result

• dApp stops with {"type":"raiden/shutdown","payload":{"reason":"raidenStopped"}}

2020-06-25T07_log.txt

Additional Infos (Optional)

[kelsos]

That is interesting, for this to happen it means that the shutdown was called by the App. The only change of this happening is hwne the App.vue component gets destroyed.

[weilbith]

Okay, let's be a bit more precise. There are three places where Raiden gets stopped. First is the disconnect() function of the Raidne service class. This function is exclusively used by the tests for now. The next occurrence is when the user does a backup of the state. Since that's not what Christian did, also not the target. The last place where we stop Raiden is when the page gets unloaded. That is was Kelsos was referring to. So when the browser is about to unload the page, we have a hook that stops Raiden before that happens.

As I knew so far the unloading happens when you close the tab, reload or switch to a new page int the same tab. Nothing that happens automatically after a while. So which web-browser are you using @christianbrb ? Maybe they have a listing when they call to unload. For example was there an announcement that Firefox will automatically unload unused tabs to save memory. Not sure if this is already live.

My suggestion would be that we prevent the unloading. So like other web-applications with unsafed data I would call preventDefault() on this event. So this usually opens a pop-up if the user want to continue or stay on the page. I would assume that even auto-unload will respect this to protects users from eventually lost data.

[christianbrb]

I am using Firefox and it took 1-hour maximum.

[weilbith]

Okay so how did the final result looked like? A blank white page or back on the initial screen?

[christianbrb]

The final result: The connect screen has been shown.

[weilbith]

@kelsos what is your opinion on this suggestion?

My suggestion would be that we prevent the unloading. So like other web-applications with unsafed data I would call preventDefault() on this event. So this usually opens a pop-up if the user want to continue or stay on the page. I would assume that even auto-unload will respect this to protects users from eventually lost data

[kelsos]

@weilbith I am not really sure. What happened to @christianbrb was probably due to the destroy lifecycle hook of App.vue being called, not an event. So I am not sure what we would need to prevent here. I would have to check the documentation again, in regards to the Vue component lifecycle.

[weilbith]

Hmm. But shouldn't vm.$destroy() on the main component only be called on unloading the page? So I actually think we stop Raiden twice...

[kelsos]

I am not sure where the second place is. Could you point to that?

[weilbith]

Your App.destroy() is here. The window event hook within RaidenService.connect() here. Finally for the backup feature the RaidenService.getState() function here.

[weilbith]

Unfortunately I can't emit the unload event manually. But using some log messages and a persistent log I see that only the window event hook gets called. The App.destroy() does not log that is got called....

[kelsos]

ok so basically it is probably what you mentioned before, firefox unloading the tabs after a while

[weilbith]

According to my link this has been introduced on Firefox 67. So I'm definitely having it. And I would assume Christian as well. So I'll go for a long duration test now. Trying to reproduce the issue and then check if preventing the event helps.

[weilbith]

Okay yesterday it did not happen for me anymore. But I kept in running the night closed an opened it for work this morning. Visiting the tab again no caused a reload for me. Again no destroying of the App component.
So I'll try to do it again with the event preventing implementation.