wechaty/puppet-service

hostie client stuck

Closed this issue · 4 comments

windmemory commented

I found that the hostie client might get stuck when the hostie ip fetch timeout:

Here is the log:

11:46:58 INFO logoutListener BOT LOGOUT: 机器人管家 logout
11:46:59 WARN No endpoint when starting grpc client, 10 retry left. Reconnecting in 10 seconds...
11:47:05 INFO ConfigManager receive maintain mode heartbeat.
11:47:10 WARN No endpoint when starting grpc client, 9 retry left. Reconnecting in 10 seconds...
11:47:20 WARN No endpoint when starting grpc client, 8 retry left. Reconnecting in 10 seconds...
11:47:31 WARN No endpoint when starting grpc client, 7 retry left. Reconnecting in 10 seconds...
11:47:42 WARN No endpoint when starting grpc client, 6 retry left. Reconnecting in 10 seconds...
undefined
11:47:57 ERR PuppetHostie start() rejection: discoverHostieIp() timeout to get any ip info from all hostie endpoints.
11:47:57 WARN Puppet reset() exception: Error: discoverHostieIp() timeout to get any ip info from all hostie endpoints.
11:47:57 ERR errorListener Error happened:
Error
    at PuppetHostie.puppet.on.payload (/xiaoju-bot/node_modules/wechaty/dist/src/wechaty.js:271:44)
    at PuppetHostie.emit (events.js:182:13)
    at PuppetHostie.EventEmitter.emit (domain.js:441:20)
    at Promise.resolve.then.then.catch.e (/xiaoju-bot/node_modules/wechaty-puppet/dist/src/puppet.js:229:18)
11:48:05 INFO ConfigManager receive maintain mode heartbeat.
11:49:05 INFO ConfigManager receive maintain mode heartbeat.
11:50:05 INFO ConfigManager receive maintain mode heartbeat.
11:51:05 INFO ConfigManager receive maintain mode heartbeat.
11:52:05 INFO ConfigManager receive maintain mode heartbeat.
11:53:05 INFO ConfigManager receive maintain mode heartbeat.

So the reason is that, when we get the hostie ip failed, usually we got a 0.0.0.0 result back, and we have logic to deal with it, but we don't have logic to deal with when all ip fetches are timeout, which I think we should handle it the same as the 0.0.0.0. So we need to fix this.

huan commented

Thanks for catching this edge case!

From another view of this problem: I believe that the API should return an HTTP 404 NOT FOUND when there's no hostie token found, instead of returning the IP of 0.0.0.0.

windmemory commented

From another view of this problem: I believe that the API should return an HTTP 404 NOT FOUND when there's no hostie token found, instead of returning the IP of 0.0.0.0.

I agree, this would be better, but this will be a breaking change.

huan commented

Yes, it's a breaking change.

I'll design the API system in the following months, and would love to include this breaking change.

windmemory commented

Great, looking forward to see the new API system. Let's close this issue for now since the bug has been fixed in v0.10.2.