Skip to content

Conversation

@MrY-Cat
Copy link
Contributor

@MrY-Cat MrY-Cat commented Apr 3, 2025

在提出此拉取请求时,我确认了以下几点(请复选框):

  • 我已阅读并理解贡献文档
  • 我已检查没有与此请求重复的 Pull Requests。
  • 我已经考虑过,并确认这份呈件对其他人很有价值。
  • 我接受此提交可能不会被使用,并根据维护人员的意愿关闭 Pull Requests。

填写PR内容:

MrY-Cat added 2 commits April 3, 2025 14:27
之前以为这个只负责设置管理员,没判断operation,导致移除管理也会抛出异常;增加了函数注释;611版本modifyAdmin会增加2-3秒响应时间,前面的管理人数判定没必要了,反正也不精确,后面的够用,删了看看响应能不能快点;还有似乎刚设置完管理更新不及时,再移除管理的时候会说他不是管理,所以把impl.role = if (operation) "admin" else "member"又加回来了,然后仅在operation==true才queryUpdate()
对齐代码样式;本来在IDEA提交的,但是他崩了,而且拉取的代码拉不到最新的。。
@MrXiaoM MrXiaoM merged commit b30efcf into MrXiaoM:main Apr 3, 2025
1 check passed
@MrY-Cat
Copy link
Contributor Author

MrY-Cat commented Apr 3, 2025

#135

@MrY-Cat
Copy link
Contributor Author

MrY-Cat commented Apr 3, 2025

@MrXiaoM 这次修改后,响应速度大部分时候变回正常了,授予和取消管理也正常了,超出人数的异常和捕捉也正常了。

但是有一个问题是,上次611版本取消管理时,取消完毕抛出了那个不该抛的异常,然后导致这次bot重启后,bot依旧把对方当做管理员,除非再次取消它,可是这个信息不是本地存的吧,按理说overflow更新到613然后bot都重启了,应该算是从onebot重新获取的信息,怎么会是错的呢,毫无头绪。。除此之外一切正常

a06104b7-c65d-4e9b-bbf2-78035f8b8ef9

@MrY-Cat
Copy link
Contributor Author

MrY-Cat commented Apr 3, 2025

只有对大吃货才发生这个情况,其余非管理员可以正常,一种可能是之前的操作导致napcat存储的数据出现错误,重启napcat后若问题消失,则大概是这样了;
网络日志:
2025-04-03 14:59:33 D/Onebot: [Recv] <-- {"time":1743663573,"self_id":2860688653,"post_type":"notice","group_id":788900848,"user_id":2278010681,"notice_type":"group_recall","operator_id":2278010681,"message_id":143107577}
2025-04-03 14:59:35 D/Onebot: [Recv] <-- {"self_id":2860688653,"user_id":2278010681,"time":1743663574,"message_id":217918827,"message_seq":217918827,"real_id":217918827,"message_type":"group","sender":{"user_id":2278010681,"nickname":"顺心寻意","card":"复读鸽","role":"admin"},"raw_message":"设置管理[CQ:at,qq=3330752746]","font":14,"sub_type":"normal","message":[{"type":"text","data":{"text":"设置管理"}},{"type":"at","data":{"qq":"3330752746"}}],"message_format":"array","post_type":"message","group_id":788900848}
2025-04-03 14:59:35 D/Onebot: [Send] --> {"action":"send_group_msg","params":{"group_id":788900848,"message":[{"type":"at","data":{"qq":"2278010681"}},{"type":"text","data":{"text":" "}},{"type":"text","data":{"text":"\n "}},{"type":"text","data":{"text":"他已经是管理员了,还设置什么啊~敲你"}}],"auto_escape":false},"echo":45}
2025-04-03 14:59:36 D/Onebot: [Recv] <-- {"status":"ok","retcode":0,"data":{"message_id":646036297},"message":"","wording":"","echo":45}

@MrY-Cat
Copy link
Contributor Author

MrY-Cat commented Apr 3, 2025

更多测试表明,不是napcat的问题,似乎和之前的头衔是类似的,bot上线后有发过言的,他的管理员状态是反的

不会又是那个什么shamrak残留吧

@MrY-Cat
Copy link
Contributor Author

MrY-Cat commented Apr 3, 2025

更多测试表明,不是napcat的问题,似乎和之前的头衔是类似的,bot上线后有发过言的,他的管理员状态是反的

不会又是那个什么shamrak残留吧

找到大致问题了,应该是和这里冲突了,造成状态不稳定:

image

我想想怎么改

@MrY-Cat
Copy link
Contributor Author

MrY-Cat commented Apr 3, 2025

image

当对同一成员快速取消管理又设置管理时,第一个事件的此处代码可能会与第二个modify中对role的修改冲突,导致最终member的permission异常,是偶发bug,需要卡好时间点,两次之间不能太快不能太慢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants