对接Lagrange.Core出现问题

caelum-lux commented 5 months ago

报错日志：


2024-02-01 18:05:33 [W] app TypeError: Cannot read properties of undefined (reading 'toString'),
                            at Receiver.receiverOnMessage (/koishi/node_modules/ws/lib/websocket.js:1209:20),
                            at Receiver.emit (node:events:518:28),
2024-02-01 18:10:26 [I] adapter connect to server: ws://127.0.0.1:9081/,
                            at decodeUser (/koishi/node_modules/koishi-plugin-adapter-onebot/lib/utils.js:35:38),
2024-02-01 18:10:31 [W] app TypeError: Cannot read properties of undefined (reading 'toString'),
                            at adaptMessage (/koishi/node_modules/koishi-plugin-adapter-onebot/lib/utils.js:134:43),
                            at adaptSession (/koishi/node_modules/koishi-plugin-adapter-onebot/lib/utils.js:208:15),
                            at dispatchSession (/koishi/node_modules/koishi-plugin-adapter-onebot/lib/utils.js:196:27),
                            at WebSocket.<anonymous> (/koishi/node_modules/koishi-plugin-adapter-onebot/lib/ws.js:81:41),
                            at callListener (/koishi/node_modules/ws/lib/event-target.js:290:14),
                            at WebSocket.onMessage (/koishi/node_modules/ws/lib/event-target.js:209:9),
                            at WebSocket.emit (node:events:518:28)

配置

TTsdzb commented 5 months ago

建议贴一下报错时拉格兰侧的日志。可能跟 #11 是类似的问题？

我认为 Onebot 适配器应该直接假定 user.id 等应该是数字的类型可以转为 number 并直接做这个转换。Onebot 11 是专门给 QQ 设计的，不需要考虑其他平台的 UID 格式。同时根据标准，user_id、group_id 等全部是数字，不应向 API 发送其他类型的数据。如果说因为 go-cqhttp 能正常识别请求就认为适配器行为正常，那这适配器干脆叫 koishi-plugin-adapter-gocqhttp 得了，还要啥 Onebot（

shigma commented 5 months ago

应当承认 OneBot 11 的实际标准实现只有 go-cqhttp 一家。作为一个已经淡出历史舞台的协议，我不认为需要为特定实现修改已经写好的逻辑。如果特定实现宣称它符合标准行为且选择与 go-cqhttp 行为不一致，那么任何使用了 OneBot 11 协议的已有代码（实际上对接的是 go-cqhttp）都无法在该实现下运行，该实现显然只会导致生态分裂。

TTsdzb commented 5 months ago

事实上确实只有 go-cqhttp 一家，但我们最终对接的是 Onebot 协议而不是 go-cqhttp。就好比我们平时使用 HTTP(S) 浏览网页，但并不关心服务端究竟是 Apache，Nginx 还是其他的什么，只要根据协议规定传输数据即可。既然我们是 Onebot 适配器，我们应当遵循 Onebot 的规范，而不是 go-cqhttp 的。

如果已有代码使用了 go-cqhttp 独有的功能，那它应当自行承担实现跑路接口失效的风险，因为它对接的是具体实现而不是通用的协议。

我认为类型这个问题应当更改，是因为 Onebot 确实规定了这个东西就是数字类型。如果适配器适配了 Onebot 协议之外的接口，但在新的软件上这个接口没有实现，那我认为确实无需更改，因为仅使用了 Onebot 标准功能的插件并不会出现问题，只有使用了这些协议之外的功能的插件不能正常工作（如上所述，它们需自行承担修改代码的额外工作）。但如果一个协议标准内的适配与标准规定有所不同，那么在更换实现后，所有规规矩矩使用协议的插件都有可能无法工作，导致所有开发者都不得不检查他们的插件。这违背了协议最初的目的，导致了本应无需为接口失效担心的开发者承担了这些风险。

shigma commented 5 months ago

我看了下实现，现在同时支持了 number 和 string 的接收。也就是说这个插件是按照协议标准来实现的，只是额外支持了 go-cqhttp 相关的内容。

如果你认为有与协议不符的地方，可以指出。

事实上，你提到的 #11 最终也证明是本插件采用了正确的实现。建议质疑之前先进行调研。

caelum-lux commented 5 months ago

我看了下实现，现在同时支持了 number 和 string 的接收。也就是说这个插件是按照协议标准来实现的，只是额外支持了 go-cqhttp 相关的内容。

如果你认为有与协议不符的地方，可以指出。

事实上，你提到的 #11 最终也证明是本插件采用了正确的实现。建议质疑之前先进行调研。

6.4.1版本已经可以正常对接了，感谢

koishijs / koishi-plugin-adapter-onebot

对接Lagrange.Core出现问题 #16