No response after chatting with the robot (与机器人私聊后无任何响应)

[mshuang2516]

本人通过 lprintf /easy-matrix-wechaty 项目的一键搭建脚本搭建服务器，搭建无任何报错， 邀请机器人进入房间后有收到“This room has been registered as your bridge management/status room.” 之后发送任何信息机器人无任何响应 log如下： 10:27:34 VERB SuperEvent constructor(request[event_id]="$CcmuRlGpx2W3tH0vxsYsxLBAE7fFhYSGn19KLLnHaWw", context[sender]="@admin.*.org", appserviceManager, wechatyManager.count()=0)
10:27:34 VERB MatrixHandler process({type: m.room.message})
10:27:34 VERB SuperEvent isRoomInvitation() for event id: $CcmuRlGpx2W3tH0vxsYsxLBAE7fFhYSGn19KLLnHaWw 10:27:34 SILL SuperEvent isRoomInvitation() -> false
10:27:34 VERB MatrixHandler processMatrixMessage(superEvent)
10:27:34 VERB MatrixHandler processMatrixMessage() skipping event due to age 1619 > 300

[lprintf]

Sorry, I have been busy moving these few days, and I am late to reply.
This seems to be a message timeout problem, but it is more likely to be related to the system time setting. Our default threshold is 5 minutes. Normal network environment is unlikely to time out. Can the bug be reproduced stably using other new docker environments? In addition, I will add an environment variable to control the timeout threshold. You can set it large enough in the new version of wechaty-matrix to avoid this situation.

抱歉，这几天搬寝室比较累，回复晚了。 这似乎是一个消息超时问题，但更可能和系统时间设置有关。我们默认的阈值是5分钟，正常网络环境不太可能超时。使用其他新的docker环境能稳定复现该bug么？ 此外，我会添加一个环境变量控制超时阈值，您可以在新版本的wechaty-matrix中把它设置得足够大来避免这种情况。

[lprintf]

You can also check your own deployment steps against this video.

你也可以对照这个视频来检查自己的部署步骤。

[mshuang2516]

Sorry, I have been busy moving these few days, and I am late to reply.
This seems to be a message timeout problem, but it is more likely to be related to the system time setting. Our default threshold is 5 minutes. Normal network environment is unlikely to time out. Can the bug be reproduced stably using other new docker environments? In addition, I will add an environment variable to control the timeout threshold. You can set it large enough in the new version of wechaty-matrix to avoid this situation.

抱歉，这几天搬寝室比较累，回复晚了。 这似乎是一个消息超时问题，但更可能和系统时间设置有关。我们默认的阈值是5分钟，正常网络环境不太可能超时。使用其他新的docker环境能稳定复现该bug么？ 此外，我会添加一个环境变量控制超时阈值，您可以在新版本的wechaty-matrix中把它设置得足够大来避免这种情况。

之前我除了使用一键搭建外也用常规方法操作过一次，也有同样的问题，并且也调了时区，也没能解决。我先看看视频，看一下是否有操作错误，谢谢。

[mshuang2516]

You can also check your own deployment steps against this video.

你也可以对照这个视频来检查自己的部署步骤。

您好我检查了安装步骤，我除了修改install.sh中域名以及账号密码外无其他修改。同时进容器看时间也与系统时间一致。客户端发送请求到服务端执行也没有感觉延迟超过5分钟。我重新部署一遍看看😁

[mshuang2516]

这里我重新部署了，问题依旧存在。请问如何手动修改超时阈值？

[lprintf]

You can also check your own deployment steps against this video. 你也可以对照这个视频来检查自己的部署步骤。

您好我检查了安装步骤，我除了修改install.sh中域名以及账号密码外无其他修改。同时进容器看时间也与系统时间一致。客户端发送请求到服务端执行也没有感觉延迟超过5分钟。我重新部署一遍看看

It is not recommended to modify the domain name settings of the one-click deployment script. Even if the domain name can be resolved to your host, it may not be able to access the service on the corresponding port of the container.

不建议修改一键部署脚本的域名设置，即便域名能解析到您的主机，它也未必能访问到容器对应端口的服务。

[mshuang2516]

You can also check your own deployment steps against this video. 你也可以对照这个视频来检查自己的部署步骤。

您好我检查了安装步骤，我除了修改install.sh中域名以及账号密码外无其他修改。同时进容器看时间也与系统时间一致。客户端发送请求到服务端执行也没有感觉延迟超过5分钟。我重新部署一遍看看

It is not recommended to modify the domain name settings of the one-click deployment script. Even if the domain name can be resolved to your host, it may not be able to access the service on the corresponding port of the container.

不建议修改一键部署脚本的域名设置，即便域名能解析到您的主机，它也未必能访问到容器对应端口的服务。

不好意思表达有误，修改的是install.sh里面的

export HOST=

之后我再次搭建我重新git clone未修改任何参数直接搭建也有同样的问题

[lprintf]

You can also check your own deployment steps against this video. 你也可以对照这个视频来检查自己的部署步骤。

您好我检查了安装步骤，我除了修改install.sh中域名以及账号密码外无其他修改。同时进容器看时间也与系统时间一致。客户端发送请求到服务端执行也没有感觉延迟超过5分钟。我重新部署一遍看看

It is not recommended to modify the domain name settings of the one-click deployment script. Even if the domain name can be resolved to your host, it may not be able to access the service on the corresponding port of the container. 不建议修改一键部署脚本的域名设置，即便域名能解析到您的主机，它也未必能访问到容器对应端口的服务。

不好意思表达有误，修改的是install.sh里面的

export HOST=

之后我再次搭建我重新git clone未修改任何参数直接搭建也有同样的问题

也许我们可以进行下远程桌面，今晚还是明晚哪天有空么？这是我微信: lprintf

[mshuang2516]

我之前是在synology NAS上安装的本项目，可能是docker套件有什么奇怪的问题，我在本地电脑安装成功了。可以正常使用

[lprintf]

这确实是个奇怪的问题。容器内的时间是同步的，不同的只有客户端时间。 #100 提供的功能是一个临时的解决方案。 和src/super-event.ts:SuperEvent的构造函数中request.getData()的返回结果有关。在后面的版本中，我们将升级一些依赖包，也许能解决该问题。