wechaty/wechaty-puppet-padchat

Watchdog reset fail because `state is off()`

Opened this issue · 4 comments

huan commented
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

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.

@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

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.

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.