CPU goes crazy when opening a channel

[nephix]

Thanks for filing a bug report :-)

Steps to Reproduce

This probably does not reproduce the issue consistently, but it's what I did

1. Add new account in metamask
2. Serve dapp
3. Go to http://localhost:8080/
4. Connect via interactive signing
5. Connect to new token TTT
6. Mint 1 TTT
7. Open channel and deposit 1 TTT with hub

Expected Result

• Channel established between me and hub
• 1 TTT got deposited

Actual Result

• Open channel dialog w/ spinner for ~20mins
• Laptop gets extremely hot and loud

Additional Infos (Optional)

• Browser & version: GC Version 81.0.4044.129 (Official Build) (64-bit)
• Browser console errors: No errors
• Device / OS: macOS

Also captured a profile for ~20secs
Profile-20200428T131202.json.zip

[taleldayekh]

I've experienced the 20+ mins time to open a channel but not noticed the laptop CPU. I'll try to reproduce this later.

[nephix]

Reproduced it again, this time with subkey account, also opened channel with hub. Took >40mins
I tried again by opening a channel with a python client that I've fired up locally and it took 2-3mins

EDIT: Fired up another python client and now it's stuck since 20mins as well trying to open channel. So does not seem to be related to the hub

[christianbrb]

@andrevmatos Could you please have a look at it and pull it into the next iteration? Thanks :)

[christianbrb]

Already 6 days old. Pulling this into the iteration to get it solved.

[nephix]

Logs:

2020-05-05T10:15:53.617Z @ raiden:0x83f75850a9EAb97e9A16Bbb17C06251085b56Ed5 [info] => %c action color: #03A9F4; font-weight: bold {"type":"channel/open/failed","payload":{"code":-32000,"message":"gas required exceeds allowance (8000000) or always failing transaction"},"meta":{"tokenNetwork":"0x2001E8851d33CA476e209e37ED8db1BB9E72334F","partner":"0x1F916ab5cf1B30B22f24Ebf435f53Ee665344Acf"},"error":true}

raiden_2020-05-05T10_36_35.156Z.log

Last week it looked like some kind of race condition: I tried to deposit once and it got stuck. Then I tried it for a second time and it worked within 5mins the same account. Not sure if that info helps

[andrevmatos]

These logs and profiling doesn't seem to indicate any reason for CPU overhead beyond what's already expected by the pending animation (which can be quite heavy sometimes). Besides that, the logs and deposit behavior you mentioned seems to be consistent with some on-chain events being missed, which can cause the animation to go for longer than expected.
The SDK is more or less reliable even with losing some events, and this seems to happen on very rare conditions (mostly related when state gets cleared, which shouldn't happen), but of course isn't desirable. I'm preparing a refactoring PR of the events monitoring, which should fix this.