VError: longlink fail to connect, host:120.241.21.110, port:80: longlink socket connect timeout #98
Comments
|
WeChat has a cgi 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? |
|
Thanks for @binsee 's suggestion, it's a greate solution which will work hopefully. But it's really hard to verify that whether the sibling server ip got via Call for volunteers: if you are running into this issue frequently, leave your message in this thread. Then we can tune the new stragety together to see if it really works. |
|
Today I have upgraded Friday BOT with Puppet PadLocal v1.11, and when
Update: after about two hours retrying, login successfully finally.Old version (0.4) has the same problem |
|
OSS.Chat (running on Heroku) is experiencing the same problems today (with Wechaty Puppet PadLocal v0.4): Retrying for more than ten times already. Let's wait and see. |
|
Longlink host fail over has been added in |
friday@wechaty-contributors:~/git/friday$ npm ls wechaty-puppet-padlocal
[email protected] /home/friday/git/friday
└── [email protected]The above problem will result in a QR Code that can not show problem: from http://friday.chatie.io:5200/ we can not get any QR Code for scan. Update (2 hours later)It connects successes and the bot back online!
|
|
I met the err report today, but it seems like no matter, that receving and sending some message is running fine. |
|
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 是的一直有这个错误 |
|
重新遇到这个问题，这里已经接收到 扫码和确认登录的事件。 09:52:43 INFO [PadLocalDemo] onScan: Confirmed(4) |
Have you solved it? |
|
遇到了huan那个问题，也不知道padlocal所说的1.11.14版本解决了么？看报错发现项目部署的环境突然ping不通120.232.51.42这个ip了，是我项目运行的ip地址被封了么，已经运行了几个月，突然报错的然后发现ping不通了。 |
20:17:37 ERR [Request] [tid:a39fe124], padlocal grpc request failed: 1, error: Error: 2 UNKNOWN: [tid:a39fe124] internal error
0|wx | SubRequestCancelError [VError]: [tid:a39fe124] request has been cancelled for reason: SERVER_ERROR: 2 UNKNOWN: [tid:a39fe124] internal error
0|wx | at Request._failAllPendingRequest (/root/pad-demo/node_modules/padlocal-client-ts/dist/Request.js:265:19)
0|wx | at ClientDuplexStreamImpl.<anonymous> (/root/pad-demo/node_modules/padlocal-client-ts/dist/Request.js:56:18)
0|wx | at ClientDuplexStreamImpl.emit (node:events:394:28)
0|wx | at Object.onReceiveStatus (/root/pad-demo/node_modules/@grpc/grpc-js/build/src/client.js:410:28)
0|wx | at Object.onReceiveStatus (/root/pad-demo/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:323:181)
0|wx | at /root/pad-demo/node_modules/@grpc/grpc-js/build/src/resolving-call.js:94:78
0|wx | at processTicksAndRejections (node:internal/process/task_queues:78:11) {
0|wx | jse_shortmsg: '[tid:a39fe124] request has been cancelled for reason: SERVER_ERROR',
0|wx | jse_cause: Error: 2 UNKNOWN: [tid:a39fe124] internal error
0|wx | at callErrorFromStatus (/root/pad-demo/node_modules/@grpc/grpc-js/build/src/call.js:31:19)
0|wx | at Object.onReceiveStatus (/root/pad-demo/node_modules/@grpc/grpc-js/build/src/client.js:410:73)
0|wx | at Object.onReceiveStatus (/root/pad-demo/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:323:181)
0|wx | at /root/pad-demo/node_modules/@grpc/grpc-js/build/src/resolving-call.js:94:78
0|wx | at processTicksAndRejections (node:internal/process/task_queues:78:11)
0|wx | for call at
0|wx | at ServiceClientImpl.makeBidiStreamRequest (/root/pad-demo/node_modules/@grpc/grpc-js/build/src/client.js:394:34)
0|wx | at ServiceClientImpl.action (/root/pad-demo/node_modules/@grpc/grpc-js/build/src/make-client.js:105:19)
0|wx | at new Request (/root/pad-demo/node_modules/padlocal-client-ts/dist/Request.js:41:51)
0|wx | at PadLocalClient.createRequest (/root/pad-demo/node_modules/padlocal-client-ts/dist/PadLocalClient.js:93:21)
0|wx | at PadLocalClientApi.<anonymous> (/root/pad-demo/node_modules/padlocal-client-ts/dist/PadLocalClientApi.js:276:41)
0|wx | at Generator.next (<anonymous>)
0|wx | at /root/pad-demo/node_modules/padlocal-client-ts/dist/PadLocalClientApi.js:27:71
0|wx | at new Promise (<anonymous>)
0|wx | at __awaiter (/root/pad-demo/node_modules/padlocal-client-ts/dist/PadLocalClientApi.js:23:12)
0|wx | at PadLocalClientApi.getMessageImage (/root/pad-demo/node_modules/padlocal-client-ts/dist/PadLocalClientApi.js:273:16) {
0|wx | code: 2,
0|wx | details: '[tid:a39fe124] internal error',
0|wx | metadata: Metadata { internalRepr: [Map], options: {} }
0|wx | },
0|wx | jse_info: {},
0|wx | reason: 1
0|wx | } |
|
Hi @huan , is there any update on this? This issue caused the login not able to be shown up, which is a big issue here. 8 VERB PuppetMemoryMixin setMemory(PadLocalDemo) 13:34:59 SILL [Request] [tid:5b13a81b] send event to server, seq:1, ack:undefined, type: 200, payload: {"policy":0} |
|
@padlocal , may I know what is the iplist of the longlink? why it returned those ips? And none of these ips can be pinged successfully, can you folks ping below ips successfully? Is there anything wrong here? 13:34:59 SILL [Request] [tid:5b13a81b] receive event from server, seq:1 ack:0, type:15, payload:{"longlinkupdateevent":{"longlinkhost":{"host":"117.184.242.106","port":80},"reconnectimmediately":false,"longlinkhostlistList":[{"host":"117.184.242.106","port":80},{"host":"117.184.242.105","port":80},{"host":"223.166.152.105","port":80},{"host":"223.166.152.106","port":80},{"host":"101.89.15.106","port":80},{"host":"101.89.15.105","port":80}]}} |
|
these errors seems to be thrown from this class, 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? |
|
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. |
|
My problem has been resolved after I switched to another token. However, is there any client support in the community to refund or regenerate the old token for me? Since I have not received any the reply from wechat support. |
and others
The text was updated successfully, but these errors were encountered: