这边在获取消息的时候会显示

[当前QQ版本不支持视频消息]

是因为core的QQ版本比较低吗

谢谢！

最近遇到奇怪的问题，我的机器人程序是分为两个部分：
第一部分，部署在运行mirai的服务器上，用环回127.0.0.1地址websocket连接。
第二部分，在另一台服务器上用公网地址websocket连接mirai服务器。

每天到凌晨的时候，使用公网地址连接的机器人程序就会收不到信息，但是使用环回地址连接的机器人程序仍然是正常运行的，直到我重启mirai才会解决，该问题观察了一个多星期了只会出现在凌晨的时候。

出现问题的时候，每收到一条信息的时候，mirai日志上就会出现以下报错：

[31m2022-06-26 07:26:28 E/Mah Debug: java.util.concurrent.CancellationException: ArrayChannel was cancelled java.util.concurrent.CancellationException: ArrayChannel was cancelled at kotlinx.coroutines.channels.AbstractChannel.cancel(AbstractChannel.kt:656) at kotlinx.coroutines.channels.ReceiveChannel$DefaultImpls.cancel$default(Channel.kt:279) at io.ktor.http.cio.websocket.DefaultWebSocketSessionImpl$runOutgoingProcessor$1.invokeSuspend(DefaultWebSocketSessionImpl.kt:182) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106) at kotlinx.coroutines.EventLoop.processUnconfinedEvent(EventLoop.common.kt:69) at kotlinx.coroutines.DispatchedTaskKt.resumeUnconfined(DispatchedTask.kt:245) at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:161) at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:397) at kotlinx.coroutines.CancellableContinuationImpl.cancel(CancellableContinuationImpl.kt:183) at kotlinx.coroutines.CancellableContinuationImpl.parentCancelled$kotlinx_coroutines_core(CancellableContinuationImpl.kt:190) at kotlinx.coroutines.ChildContinuation.invoke(JobSupport.kt:1474) at kotlinx.coroutines.JobSupport.notifyCancelling(JobSupport.kt:1499) at kotlinx.coroutines.JobSupport.tryMakeCancelling(JobSupport.kt:795) at kotlinx.coroutines.JobSupport.makeCancelling(JobSupport.kt:755) at kotlinx.coroutines.JobSupport.cancelImpl$kotlinx_coroutines_core(JobSupport.kt:671) at kotlinx.coroutines.JobSupport.parentCancelled(JobSupport.kt:637) at kotlinx.coroutines.ChildHandleNode.invoke(JobSupport.kt:1465) at kotlinx.coroutines.JobSupport.notifyCancelling(JobSupport.kt:1499) at kotlinx.coroutines.JobSupport.tryMakeCompletingSlowPath(JobSupport.kt:900) at kotlinx.coroutines.JobSupport.tryMakeCompleting(JobSupport.kt:863) at kotlinx.coroutines.JobSupport.cancelMakeCompleting(JobSupport.kt:696) at kotlinx.coroutines.JobSupport.cancelImpl$kotlinx_coroutines_core(JobSupport.kt:667) at kotlinx.coroutines.JobSupport.parentCancelled(JobSupport.kt:637) at kotlinx.coroutines.ChildHandleNode.invoke(JobSupport.kt:1465) at kotlinx.coroutines.JobSupport.notifyCancelling(JobSupport.kt:1499) at kotlinx.coroutines.JobSupport.makeCancelling(JobSupport.kt:747) at kotlinx.coroutines.JobSupport.cancelImpl$kotlinx_coroutines_core(JobSupport.kt:671) at kotlinx.coroutines.JobSupport.parentCancelled(JobSupport.kt:637) at kotlinx.coroutines.ChildHandleNode.invoke(JobSupport.kt:1465) at kotlinx.coroutines.JobSupport.notifyCancelling(JobSupport.kt:1499) at kotlinx.coroutines.JobSupport.tryMakeCancelling(JobSupport.kt:795) at kotlinx.coroutines.JobSupport.makeCancelling(JobSupport.kt:755) at kotlinx.coroutines.JobSupport.cancelImpl$kotlinx_coroutines_core(JobSupport.kt:671) at kotlinx.coroutines.JobSupport.parentCancelled(JobSupport.kt:637) at kotlinx.coroutines.ChildHandleNode.invoke(JobSupport.kt:1465) at kotlinx.coroutines.JobSupport.notifyCancelling(JobSupport.kt:1499) at kotlinx.coroutines.JobSupport.tryMakeCancelling(JobSupport.kt:795) at kotlinx.coroutines.JobSupport.makeCancelling(JobSupport.kt:755) at kotlinx.coroutines.JobSupport.cancelImpl$kotlinx_coroutines_core(JobSupport.kt:671) at kotlinx.coroutines.JobSupport.parentCancelled(JobSupport.kt:637) at kotlinx.coroutines.ChildHandleNode.invoke(JobSupport.kt:1465) at kotlinx.coroutines.JobSupport.notifyCancelling(JobSupport.kt:1499) at kotlinx.coroutines.JobSupport.tryMakeCancelling(JobSupport.kt:795) at kotlinx.coroutines.JobSupport.makeCancelling(JobSupport.kt:755) at kotlinx.coroutines.JobSupport.cancelImpl$kotlinx_coroutines_core(JobSupport.kt:671) at kotlinx.coroutines.JobSupport.cancelInternal(JobSupport.kt:632) at kotlinx.coroutines.JobSupport.cancel(JobSupport.kt:617) at kotlinx.coroutines.JobKt__JobKt.cancel(Job.kt:549) at kotlinx.coroutines.JobKt.cancel(Unknown Source) at kotlinx.coroutines.JobKt__JobKt.cancel$default(Job.kt:548) at kotlinx.coroutines.JobKt.cancel$default(Unknown Source) at io.ktor.server.cio.backend.ServerPipelineKt$startServerConnectionPipeline$1.invokeSuspend(ServerPipeline.kt:179) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104) at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:749) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

机器人程序都是使用Ariadne SDK写的
mirai 2.11.0
mirai-http2.5.2
Ariadne 0.7.14

希望大佬们可以帮忙看看，谢谢！
现在每天早上起来第一件事就是重启mirai o(╥﹏╥)o
打算写一个定时重启脚本临时用着

Dockerfile：https://github.com/Slontia/my-dockers/tree/master/mirai-mcl-http

下载镜像：docker pull slontia/mirai-mcl-http:latest

顺便搞的一个东西，将 mirai-api-http 和自己用 mirai-cpp 实现的客户端，分别打包成了两个 Docker 镜像。上面的只是 mirai-api-http 的 Docker 镜像，包括 mcl 本体 + mirai-api-http 插件。

具体使用，可以参考 https://github.com/Slontia/lgtbot-mirai/wiki/使用-Docker-启动-lgtbot-mirai

我现在的场景是将mirai和mirai-http作为一个独立的模块部署在docker中，其他模块通过通过http与mirai通信。
我会把通过websocket收到的每一条消息存入记录表，以供回复消息的场景使用。
如果我重新打包部署mirai，那么mirai的缓存消息将会清空，这导致新生成的messageId可能会和已经清理掉的缓存消息的messageId重复。(推测的重复原因)
希望生成新的messageId的时候，加入时间戳参数，使mirai即使重新打包部署也能不出现重复的messageId。:P

这是我的代码

import requests md = {'sessionKey':'XXXXXXX','target':711XXXXX96,'messageChain':[{'type':'Plain','text':'hello'},{'type':'Plain','text':'world'}]} headers = {'Content-Type': 'application/json'} r4 = requests.post('http://XXXXXXXXX/sendGroupMessage',data=json.dumps(md),headers=headers)

结果是400，参数错误。我试了不把json转化成字符串，也发生了参数错误，请问我应该怎么做？

截屏2022-05-19 上午8.22.27.png

这是一个上传函数类里的一个方法，但是这个语音文件为什么上传不上去啊是参数有问题吗🤔上传提示，文件上传失败

QQ图片20220517200334.png
求助

请问Mirai生态有办法使用HTTP API来登陆新账号吗？

BotConfiguration botConfiguration = new BotConfiguration(); botConfiguration.setLoginSolver(new MyLoginSolver()); botConfiguration.fileBasedDeviceInfo(); Bot register = miraiBotManager.register(code, password, botConfiguration); //MyLoginSolver @Nullable @Override public Object onSolveSliderCaptcha(@NotNull Bot bot, @NotNull String url, @NotNull Continuation<? super String> continuation) { MiraiLogger logger = bot.getLogger(); System.out.println("验证码地址：" + url); logger.info("验证码url：" + url); return standardCharImageLoginSolver.onSolveSliderCaptcha(bot, url, continuation); }

登录时并未打印url

b5328c5c-a13a-4c71-9676-500222c3bc15-image.png

{'code': 0, 'msg': 'success', 'messageId': -1}
调用http-api-2.4
console中日志记录显示已经发送图片，但是群里看不到信息，换个qq就正常了，就只是群发图片存在异常，文字、语音群发送都是正常的，有大佬碰到这个问题么

最近VRchat更新了OSC，我想利用OSC做一个QQ消息的游戏内提醒，关于OSC的部分我已经完成了，但如何得到QQ收到消息的动作却难倒了我，有大佬可以给点建议么？（我并不需要消息的内容，只需要知道收到消息的数量和发送消息的好友）

场景

我需要通过Docker Compose自动化启动mcl，和mah实现的bot

遇到的问题

mcl刚启动时，autologin的用户还未成功登录，但此时已经mah已打开，甚至HTTPAdapter下的/verifyapi可以正常调用。

而HTTPAdapter下的/bind，以及WebsocketAdapter下的/verify则可能会不确定性地出现两种情况：

此API调用直接返回机器人不存在 此API正常调用，但是后续API依然无法正确响应，直到登陆成功 暂时解决方案

循环调用登录api，直到返回正确结果

期望的解决方案

我看到mirai-core中确实有对bot是否在线的判断

/** * 判断 Bot 是否在线 (可正常收发消息) */ @SinceMirai("1.0.1") abstract val isOnline: Boolean

所以mirai-api-http能增加一个api来判断此状态

对BotOnlineEvent的思考

感觉BotOnlineEvent事件有点鸡肋，正常情况下mah连接到mcl时，账号早已登录完成，mah根本收不到此事件。而上述情况中，bot的启动阶段是希望阻塞式地判断是否登陆成功的，用事件的方式似乎又不太优雅。

我现在正在使用Amiya-Bot和ChatLearning两个程序，两个程序都要求使用http接口，应该怎样正确书写mirai-api-http的配置文件呢？
我目前的配置文件是这样的：

adapters: - http - ws debug: false enableVerify: true verifyKey: AmiyaBot singleMode: false cacheSize: 4096 adapterSettings: http: host: 127.0.0.1 port: 8096 cors: [*] ws: host: 127.0.0.1 port: 8060 reservedSyncId: -1 http: host: 127.0.0.1 port: 8097 cors: [*]

这样使用的话会出现两个程序都无法正确上报回复内容，应该怎么修改呢？
如果我想使用两个不同的verifyKey的话，应该怎么书写呢？

Mirai运行在服务器上，用MCL启动，安装了mirai-api-http。启动及登录无报错，并显示指定端口已监听（http和ws）。VPS供应商的安全组开放了指定端口的入站，未启用UFW，iptables对端口放行并且每次请求可以看到有5个packet进来，netstats也显示端口正在被监听。
同一端口被redir到nodejs端口的时候GET请求可以获取到网站首页，然后立即修改成redir到监听端口则请求被拒。控制变量法看的话大概确实是http-api的问题？

配置文件如下：

adapters: - http - ws enableVerify: true verifyKey: {secret} debug: true singleMode: true cacheSize: 4096 adapterSettings: http: host: localhost port: 8080 cors: [*] ws: host: localhost port: 8080 reservedSyncId: -1

端口也尝试过14519 14518之类的，症状相同。

感谢！

最近发现我的bot在复读消息时，如果消息内有图片(或只是图片)的消息，有概率会出现消息显示发送成功了但是qq里没有内容
286abd3b-f98f-41c3-8b5f-5ca37b63c444-image.png
617d111c-2721-41ab-85e3-d2a936b5eab6-image.png
但是直接发送图片却能成功
9b54cb31-5ff0-49a7-938e-43fd1928e58c-image.png
这是因为腾讯什么奇奇怪怪的检测吗

尝试使用Rubirai写插件,但是要求需要authkey,而github上的链接已失效、在mirai-api-http的API文档中也没有找到相关教程。
故求问论坛各位大佬 如何获取authkey（
https://pic4.58cdn.com.cn/nowater/webim/big/n_v2328a6c98425745ccae800817795a4eae.png
图中的authkey链接指向的是github上的文档.

Rubirai是mirai-api-http插件的Ruby类库

>>> t=time.time();data=r.get("http://localhost:8080//peekLatestMessage?count=10").text;print(time.time()-t) 2.0292623043060303

获取消息一次要两秒，发消息也差不多，稍微再多点