search

wechaty / wechaty-puppet-padchat

Padchat Puppet for Wechaty
https://www.npmjs.com/package/wechaty-puppet-padchat
Apache License 2.0
279 stars 46 forks source link

Watchdog reset fail because `state is off()` #163

Open huan opened 6 years ago

huan commented 6 years ago 
2018-08-27T02:40:25.248808+00:00 app[web.1]: 10:40:25 SILL StateSwitch <Wechaty> on() is true
2018-08-27T02:40:33.155426+00:00 app[web.1]: 10:40:33 SILL Puppet constructor() watchdog.on(reset) reason: {"data":"ws.on(message)","timeout":240000}
2018-08-27T02:40:33.155605+00:00 app[web.1]: 10:40:33 SILL Puppet constructor() this.on(reset) reason: {"data":"ws.on(message)","timeout":240000}
2018-08-27T02:40:33.155788+00:00 app[web.1]: 10:40:33 SILL Puppet constructor() resetThrottleQueue.subscribe() reason: {"data":"ws.on(message)","timeout":240000}
2018-08-27T02:40:33.155866+00:00 app[web.1]: 10:40:33 VERB Puppet reset({"data":"ws.on(message)","timeout":240000})
2018-08-27T02:40:33.156000+00:00 app[web.1]: 10:40:33 SILL StateSwitch <PuppetPadchat> off() is pending
2018-08-27T02:40:33.156125+00:00 app[web.1]: 10:40:33 VERB Puppet reset({"data":"ws.on(message)","timeout":240000}) state is off(), do nothing.
2018-08-27T02:40:35.253789+00:00 app[web.1]: 10:40:35 SILL StateSwitch <Wechaty> on() is true

Related to: https://github.com/caiyunapp/caiyun-wechaty/issues/16

huan commented 6 years ago

It seems this is because when we are recovering from the WebSocket reset, there's some problem caused we set state.off(true) which should not.

windmemory commented 6 years ago

@zixia Could you provide more logs for this issue? From the logs that you pasted above, it is not clear whether this is the first time reset get called or not. If not, then the behavior is expected.

huan commented 6 years ago

This it's not the first time. And even it's the first time i still not expect this kind of behavior.

Yes, we need more log.

This log is come from caiyun, I have no more but let's keep a eye on this kind of problems in the future.

windmemory commented 6 years ago

I agree with you that this should not happen if this is the first time calling reset().

But if this is not the first time calling reset(), then the state is off makes some sense here. It means the reset process is stuck half way somewhere, and we do not want to do reset() anymore since there is one ongoing or failed (Well, in this case, still bug :P ).

Anyway, let's keep an eye on this problem.