Repository navigation
feat(services/answer-platform-v26): add 全悉 V26.07.002 API-Token service - #562
Conversation
|
PR Title: feat(services/answer-platform-v26): add 全悉 V26.07.... Commit: 整体评估本变更新增 Chaitin Answer-Platform V26.07.002 的 OctoBus 服务包，以 JSON-RPC over HTTP 方式封装 16 个只读接口，并补齐 proto、配置/密钥 schema、服务注册、文档与单元测试。整体结构清晰，参数映射与错误码转换覆盖较完整，但代理与响应大小控制两处实现与配置说明不一致，存在运行期风险。 总结新增服务可正常覆盖主要查询场景，但需在合并前修正代理协议处理（当前仅支持 SOCKS，却宣称支持 HTTP 代理）以及响应大小限制的实际执行时机，避免配置 HTTP 代理后全部请求失败、超大响应先占满内存。 Findings (2)
Prompt To Fix All With AI |
![monkeyscan[bot]](https://avatars.githubusercontent.com/u/231811742?s=60&v=4){kind=small}
| const target = new URL(url); | ||
| const mod = target.protocol === 'https:' ? https : http; | ||
| const agent = new SocksProxyAgent(proxyUrl); | ||
|
|
There was a problem hiding this comment.
🟡 配置声明支持 HTTP 代理，但代理实现只支持 SOCKS，配置 http:// 代理时请求会失败
Category: 功能正确性
config.schema.json 和 README 把 proxy_url/proxyUrl 描述为可配置 HTTP/SOCKS 代理，但 proxiedFetch 固定用 SocksProxyAgent 建立连接，而该库只接受 SOCKS 协议地址。用户按文档配置 http:// 或 https:// 代理时，构造 Agent 或后续握手中会直接报错，导致该实例所有请求失败。
Problem code:
Recommendation:
按代理协议选择实现：SOCKS 用 SocksProxyAgent，HTTP/HTTPS 用 undici ProxyAgent（或 http-proxy-agent）；若确实只支持 SOCKS，则修改 schema 描述和 README，并在 rpcCall 中校验 proxyUrl 协议、返回明确的 INVALID_ARGUMENT。
Prompt To Fix All With AI
This is a comment left during a code review.
Repository: https://github.com/chaitin/OctoBus
Path: services/chaitin__answer-platform_v26-07-002/src/answer-platform-v26.js
Line: 196-200
Comment:
配置声明支持 HTTP 代理，但代理实现只支持 SOCKS，配置 http:// 代理时请求会失败
config.schema.json 和 README 把 proxy_url/proxyUrl 描述为可配置 HTTP/SOCKS 代理，但 proxiedFetch 固定用 SocksProxyAgent 建立连接，而该库只接受 SOCKS 协议地址。用户按文档配置 http:// 或 https:// 代理时，构造 Agent 或后续握手中会直接报错，导致该实例所有请求失败。
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
| throw errorWithCode('INTERNAL', `upstream response exceeds ${maxResponseBytes} bytes`); | ||
| } | ||
| return text; | ||
| }; |
There was a problem hiding this comment.
🟡 maxResponseBytes 在完整读取响应后才校验，超大响应仍会先占满内存
Category: 稳定性与可用性
readResponseText 先 await res.text() 再比较 Buffer.byteLength，代理分支也在 proxiedFetch 中先把全部 chunk 合并成字符串，因此超过 maxResponseBytes 的上游响应会被完整缓存到内存后才被拒绝。配置的响应大小上限无法在读取过程中保护长运行进程，异常或恶意上游返回超大响应时可能造成内存耗尽。
Problem code:
Recommendation:
改为流式读取：在 data 事件中累计字节数，一旦超过 maxResponseBytes 立即销毁请求/响应并返回错误；代理分支同样在 chunk 累积处执行上限检查，避免先整体缓冲。
Prompt To Fix All With AI
This is a comment left during a code review.
Repository: https://github.com/chaitin/OctoBus
Path: services/chaitin__answer-platform_v26-07-002/src/answer-platform-v26.js
Line: 237-247
Comment:
maxResponseBytes 在完整读取响应后才校验，超大响应仍会先占满内存
readResponseText 先 await res.text() 再比较 Buffer.byteLength，代理分支也在 proxiedFetch 中先把全部 chunk 合并成字符串，因此超过 maxResponseBytes 的上游响应会被完整缓存到内存后才被拒绝。配置的响应大小上限无法在读取过程中保护长运行进程，异常或恶意上游返回超大响应时可能造成内存耗尽。
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
|
PR Title: feat(services/answer-platform-v26): add 全悉 V26.07.... Commit: 整体评估本轮（提交 63c8728）在上一轮新增的全悉 V26.07.002 服务包基础上补充测试，覆盖 helpers、全部 handler、代理传输与错误码映射，生产代码未发生变化，整体方向正确。 总结测试补充本身未发现新的可执行缺陷；但上一轮指出的两个源码问题仍未修复：proxy_url 宣称支持 HTTP 代理却只用 SocksProxyAgent 实现，以及 maxResponseBytes 在完整读取响应后才校验。建议合并前修复这两项。 |
- 基于 V26.07.002 OpenAPI，16 个只读方法 - 覆盖告警 / license / 资产查询等只读能力
- cover all 16 RPC handlers, transport helpers and error mappings - cover proxiedFetch socks5 transport via mocked http.request - cover oversized response and JSON-RPC error code branches
63c8728 to
b6539a5
Compare
|
PR Title: feat(services/answer-platform-v26): add 全悉 V26.07.... Commit: 整体评估本次新增全悉 V26.07.002 OpenAPI 只读服务，包含 16 个 JSON-RPC 代理方法、proto 定义、配置/密钥 schema，以及服务注册和较完整的单元测试。整体接入方式与既有服务保持一致，查询逻辑和错误映射清晰，主要风险集中在网络传输层的资源限制与超时控制。 总结总体方向正确、集成完整，但响应大小上限与超时机制无法在传输过程中真正生效，且文档宣称支持的 HTTP 代理实际不可用，可能导致内存/连接耗尽或按文档配置后请求全部失败，建议合入前修复。现有测试未覆盖这些传输层边界场景。 Findings (3)
Prompt To Fix All With AI |
| const target = new URL(url); | ||
| const mod = target.protocol === 'https:' ? https : http; | ||
| const agent = new SocksProxyAgent(proxyUrl); | ||
|
|
There was a problem hiding this comment.
🟡 配置宣称支持 HTTP 代理，但代理实现只支持 SOCKS，http:// 代理会导致请求失败
Category: 功能正确性
config.schema.json 与 README 把 proxy_url/proxyUrl 描述为可配置 HTTP/SOCKS 代理，但 proxiedFetch 固定使用 SocksProxyAgent，而该库只接受 socks 协议地址。用户按文档配置 http:// 或 https:// 代理时会在创建 Agent 时报错，导致该实例的所有请求失败。
Problem code:
Recommendation:
要么用 undici 的 ProxyAgent 支持 http(s) 代理并按 scheme 选择代理 Agent，要么把配置 schema 和 README 明确限定为仅支持 socks 代理。
Prompt To Fix All With AI
This is a comment left during a code review.
Repository: https://github.com/chaitin/OctoBus
Path: services/chaitin__answer-platform_v26-07-002/src/answer-platform-v26.js
Line: 196-200
Comment:
配置宣称支持 HTTP 代理，但代理实现只支持 SOCKS，http:// 代理会导致请求失败
config.schema.json 与 README 把 proxy_url/proxyUrl 描述为可配置 HTTP/SOCKS 代理，但 proxiedFetch 固定使用 SocksProxyAgent，而该库只接受 socks 协议地址。用户按文档配置 http:// 或 https:// 代理时会在创建 Agent 时报错，导致该实例的所有请求失败。
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
| throw errorWithCode('INTERNAL', `upstream response exceeds ${maxResponseBytes} bytes`); | ||
| } | ||
| return text; | ||
| }; |
There was a problem hiding this comment.
🟠 响应大小上限在完整读完响应后才校验，超大响应仍会先占满内存
Category: 稳定性与可用性
readResponseText 先 await res.text() 再比较 Buffer.byteLength，代理分支也在 proxiedFetch 中把所有 chunk 合并成完整字符串后才返回，因此 maxResponseBytes 无法在读取过程中生效。上游返回异常或恶意超大响应时，长运行进程会先把整份内容缓存进内存再拒绝，可能造成内存耗尽。
Problem code:
Recommendation:
改用流式读取，在累计字节数超过 maxResponseBytes 时立即中止连接：fetch 分支通过 res.body reader 逐块累加，代理分支在 data 事件中累加并在超限时 destroy 请求。
Prompt To Fix All With AI
This is a comment left during a code review.
Repository: https://github.com/chaitin/OctoBus
Path: services/chaitin__answer-platform_v26-07-002/src/answer-platform-v26.js
Line: 237-247
Comment:
响应大小上限在完整读完响应后才校验，超大响应仍会先占满内存
readResponseText 先 await res.text() 再比较 Buffer.byteLength，代理分支也在 proxiedFetch 中把所有 chunk 合并成完整字符串后才返回，因此 maxResponseBytes 无法在读取过程中生效。上游返回异常或恶意超大响应时，长运行进程会先把整份内容缓存进内存再拒绝，可能造成内存耗尽。
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
| let json; | ||
| try { | ||
| const text = await readResponseText(res, maxResponseBytes); | ||
| json = JSON.parse(text); |
There was a problem hiding this comment.
🟡 配置的 timeoutMs 不覆盖响应体读取，拿到响应头后超时定时器即被清除
Category: 稳定性与可用性
非代理分支在 fetch 拿到响应头后就在 finally 中 clearTimeout，而响应体要等到之后的 readResponseText 才读取，因此 timeoutMs 不覆盖响应体读取阶段。上游返回响应头后缓慢发送或停止发送响应体时，请求会远超配置的超时时间甚至长时间挂起，占用长运行进程的连接。
Problem code:
Recommendation:
在读取完响应体并 parse 完成后再清除超时定时器，或把 AbortController 的 abort 逻辑覆盖到 res.text() 结束。
Prompt To Fix All With AI
This is a comment left during a code review.
Repository: https://github.com/chaitin/OctoBus
Path: services/chaitin__answer-platform_v26-07-002/src/answer-platform-v26.js
Line: 284-311
Comment:
配置的 timeoutMs 不覆盖响应体读取，拿到响应头后超时定时器即被清除
非代理分支在 fetch 拿到响应头后就在 finally 中 clearTimeout，而响应体要等到之后的 readResponseText 才读取，因此 timeoutMs 不覆盖响应体读取阶段。上游返回响应头后缓慢发送或停止发送响应体时，请求会远超配置的超时时间甚至长时间挂起，占用长运行进程的连接。
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
…ough SocksProxyAgent The smoke harness synthesizes the mock upstream as an http base URL, which was fed verbatim to SocksProxyAgent and failed every Connect call with "A socks protocol must be specified! Got: http:". Fall back to a direct connection for non-socks URLs.
Summary
新增全悉（Answer-Platform）V26.07.002 OpenAPI 版只读查询 service：
Test plan
node scripts/validate-service-package.mjs --service-dir chaitin__answer-platform_v26-07-002node --test单测（mock 上游）