17:09:05 ERR Config ###########################
17:09:05 ERR Config unhandledRejection: VError: longlink fail to connect, host:120.241.21.110, port:80: longlink socket connect timeout
at WeChatLongLinkProxy.<anonymous> (/app/node_modules/padlocal-client-ts/dist/link/WeChatLongLinkProxy.js:91:23)
at Generator.throw (<anonymous>)
at rejected (/app/node_modules/padlocal-client-ts/dist/link/WeChatLongLinkProxy.js:6:65)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (node:internal/process/task_queues:96:5) [object Promise]
17:09:05 ERR Config ###########################
17:09:05 ERR Config process.on(unhandledRejection) promise.catch(longlink fail to connect, host:120.241.21.110, port:80: longlink socket connect timeout)
Config IOError [VError]: longlink fail to connect, host:120.241.21.110, port:80: longlink socket connect timeout
at WeChatLongLinkProxy.<anonymous> (/app/node_modules/padlocal-client-ts/dist/link/WeChatLongLinkProxy.js:91:23)
at Generator.throw (<anonymous>)
at rejected (/app/node_modules/padlocal-client-ts/dist/link/WeChatLongLinkProxy.js:6:65)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (node:internal/process/task_queues:96:5) {
jse_shortmsg: 'longlink fail to connect, host:120.241.21.110, port:80',
jse_cause: IOError [VError]: longlink socket connect timeout
at Timeout.<anonymous> (/app/node_modules/padlocal-client-ts/dist/link/WeChatLongLinkProxy.js:276:39)
at listOnTimeout (node:internal/timers:557:17)
at processTimers (node:internal/timers:500:7) {
jse_shortmsg: 'longlink socket connect timeout',
jse_info: {}
},
jse_info: {}
}
(node:17) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 2)
(Use `node --trace-warnings ...` to show where the warning was created)
wechaty-puppet-padlocal@1.20.1I met the err report today, but it seems like no matter, that receving and sending some message is running fine.
WeChat has a cgi
/cgi-bin/micromsg-bin/newgetdnsfor returning a set of dns lists, which will provide users with multiple optional server IPs.In mars, the server will be selected in order. If the first ip connection fails, the second ip will be connected. The official app ensures higher usability through this mechanism.
Not sure if padlocal supports this mechanism?
17:07:42 ERR [Request] [tid:50f0aef6], padlocal grpc request failed: 3, error: IOError: [tid:50f0aef6] Exception while handling wechat request: long link send request timeout 17:07:42 WARN [LongLink] [120.232.51.42:80] close connection on error,IOError: long link init failed: [tid:50f0aef6] request has been cancelled for reason: CLIENT_ERROR: [tid:50f0aef6] Exception while handling wechat request: long link send request timeout 17:07:42 WARN [LongLink] longlink reconnect [1] after delay:1000ms
是的一直有这个错误
Thanks a lot @padlocal for helping with this! I switched to another token and it no longer has this issue, according to @padlocal it might because the ip list which was used long time ago(already invalid ips) were remebered or cached so that it returned the stale ip list, which of course will be timed out.
However, if this is the case, I would like to know, who remembered those ip list? the weixin server? Or wechaty server? It sounds like this is a bug from one certain side, if the ip cannot be connected, should we tell the server to not return the cached ip list, instead give us the newest ips? Otherwise we will timeout forever.
these errors seems to be thrown from this class, https://github.com/padlocal/padlocal-client-ts/blob/master/src/Request.ts
May I know what does the Longlink do? and even I tried several different devices and different networks, they all returned the same set of ip list, is there any cache of it? Just curious is it possible to use some workaround to make me able to login? e.g. Not using this LongLink or switch to another protocol rather than grpc prototocol?