Snow-kal opened a new issue, #3742: URL: https://github.com/apache/dubbo-go/issues/3742
## 背景 [dubbo-go#3167](https://github.com/apache/dubbo-go/issues/3167) 解决了 dubbo-go 泛化调用与 Java Dubbo 的若干基础能力差距，包括 `GenericException`、`InvokeWithType`、Gson/Bean/protobuf-json 等能力。本提案不重复实现这些 SDK 能力，而是把它们接入并明确暴露在 dubbo-admin 的服务调试流程中。 当前 Admin 已能通过 `POST /api/v1/service/generic/invoke` 调用 Dubbo/Triple provider，但用户无法明确选择或查看泛化模式，参数类型校验不足，Java 业务异常在 UI 中通常只显示统一错误文本，且缺少 Admin 到真实 Java/Go provider 的跨语言验收矩阵。 > 以下文件链接固定到提案所用代码基线；“对应内容”是定位与拟修改职责，不表示所有文件都必须修改。 ## 当前代码位置 - Admin UI：[`debug.vue`](https://github.com/apache/dubbo-admin/blob/1e56a0a7c2e8bd7921b7d03159a9f80645486270/ui-vue3/src/views/resources/services/tabs/debug.vue) - 请求模型：[`model/service.go`](https://github.com/apache/dubbo-admin/blob/1e56a0a7c2e8bd7921b7d03159a9f80645486270/pkg/console/model/service.go) - 调用入口：[`service_generic_invoke.go`](https://github.com/apache/dubbo-admin/blob/1e56a0a7c2e8bd7921b7d03159a9f80645486270/pkg/console/service/service_generic_invoke.go) - 参数解码：[`service_generic_invoke_decode.go`](https://github.com/apache/dubbo-admin/blob/1e56a0a7c2e8bd7921b7d03159a9f80645486270/pkg/console/service/service_generic_invoke_decode.go) - dubbo-go 泛化服务：[`filter/generic/service.go`](https://github.com/apache/dubbo-go/blob/832124aaacf0283445d379e935ff5d73695fa84d/filter/generic/service.go) - dubbo-go 泛化 filter：[`filter/generic/filter.go`](https://github.com/apache/dubbo-go/blob/832124aaacf0283445d379e935ff5d73695fa84d/filter/generic/filter.go) ## 具体需要实现的功能 ### 1. 在 Admin 请求中明确泛化模式和序列化方式 **问题** 目前请求体虽然包含服务、方法、签名、参数、超时和 attachments，但没有一个清晰、稳定的用户可见契约说明本次调用使用哪一种 generic mode。Admin 也不能把 provider 实际使用的 transport serialization 与泛化 mode 一起展示给用户。 **涉及文件** | 功能 | 文件 | |---|---| | 模式选择、实例序列化方式展示和调用结果展示 | `ui-vue3/src/views/resources/services/tabs/debug.vue` | | 在现有请求模型中定义、校验模式输入 | `pkg/console/model/service.go` | | 读取实例协议与序列化配置，将模式接入现有调用链 | `pkg/console/service/service_generic_invoke.go` | | 核对泛化客户端的构建、默认模式与序列化设置 | `client/client.go` | | 核对合法模式识别及 generalizer 选择 | `filter/generic/util.go` | | 核对 generic 模式下的请求重写行为 | `filter/generic/filter.go` | **方案** 1. 在 `debug.vue` 的调用区域展示 provider metadata 中可用的 generic mode 和实例 serialization。 2. 请求发送前校验 mode，只允许当前 SDK/provider 支持的值：`true`、`gson`、`bean`、`protobuf-json`；保留代码中的 legacy `protobuf` 兼容行为，不在本提案中宣称立即删除或拒绝。 3. 将 mode 传入现有调用链，由 dubbo-go `GenericService` 负责生成泛化请求；不新增第二个 HTTP route、DTO 或 client。 4. 未知 mode 直接返回字段级错误，不能降级成 Map，也不能发起 RPC。 5. `generic=false` 必须透传为非泛化调用，不能被 Admin 静默改写成 `true`。 **验收** - 用户选择一个已发现的 method/signature，选择 `gson`，提交参数；请求记录显示 `generic=gson` 和实际 serialization，provider 收到泛化调用。 - 提交 `generic=unknown`；API 返回 `field=generic` 的校验错误，provider 请求计数不增加。 - 提交 `generic=false`；请求不会经过 `$invoke` 泛化重写，结果和错误均明确显示为普通调用行为。 ### 2. 固定请求 wire 格式与 API 校验 **问题** 泛化调用必须依赖方法名、参数类型数组和参数值三元组。当前 proposal 只描述了顺序，没有规定每个输入错误的可观察结果。 **涉及文件** | 功能 | 文件 | |---|---| | 方法签名、参数及超时的请求校验 | `pkg/console/model/service.go` | | 依据元数据匹配方法，生成 SDK 参数并处理调用错误 | `pkg/console/service/service_generic_invoke.go` | | 按方法参数类型解码 args | `pkg/console/service/service_generic_invoke_decode.go` | | 核对 Invoke 接口的 method/types/args 输入约定 | `filter/generic/service.go` | | 核对泛化调用三元组的生成 | `filter/generic/filter.go` | | 核对 Triple non-IDL unary 与 reply 参数约定 | `protocol/triple/triple_invoker.go` | **方案** 1. 对 Dubbo 泛化调用固定 wire 参数为 `[methodName, types, args]`。 2. 对 Triple non-IDL 调用固定 raw values 约定，最后一项为 reply；只承诺 unary，不扩展 streaming。 3. `signature` 必须来自 provider metadata；禁止用户提交 metadata 中不存在的重载签名。 4. `len(types)` 必须等于方法参数个数，`args` 必须逐项对应 `types`。 5. `timeoutMs<=0` 继续归一为现有默认值 3000ms；attachments 原样透传。 6. 校验失败统一返回稳定 HTTP envelope，例如 `code`、`message`、`field`、`expected`、`actual`；错误发生在创建/发送 RPC 之前。 **验收** - 对 `echo(String)` 提交 `types=["java.lang.String"]`、`args=["hello"]`；provider 收到 method、types、args 顺序正确的 `$invoke`。 - 提交 `types=[]` 或未知 signature；API 返回参数数量/签名错误，provider 不收到请求。 - 提交 `timeoutMs=0` 和 attachment `traceId=abc`；实际调用超时为 3000ms，provider 能读取 attachment。 ### 3. 按 provider metadata 解码参数，禁止静默类型损失 **问题** Admin 当前解码逻辑主要覆盖 Java primitive/boxed 类型和 `T[]`，复杂嵌套对象以及 Go provider 类型名需要进一步对齐。前端 JSON 解析大整数还可能发生精度损失（待验证）。 **涉及文件** | 功能 | 文件 | |---|---| | 参数模板、重载选择、大整数输入及字段错误展示 | `ui-vue3/src/views/resources/services/tabs/debug.vue` | | 核对 RawMessage 参数载体，避免过早丢失数值信息 | `pkg/console/model/service.go` | | 按参数与嵌套字段类型进行安全解码并报告字段路径 | `pkg/console/service/service_generic_invoke_decode.go` | | 将元数据、方法签名与参数解码衔接，在错误时停止调用 | `pkg/console/service/service_generic_invoke.go` | **方案** 1. 复用现有 `buildRelatedTypes` 和 method detail，不建立第二套类型描述协议。 2. 明确支持并逐项测试：Java/Go primitive 与 boxed 类型、`long`/大整数、数组、enum、嵌套 object、map 和重载签名。 3. 对 long/大整数使用字符串输入并保持到后端；后端按 metadata 转换，无法安全转换时拒绝调用。 4. 嵌套字段错误返回完整字段路径，例如 `user.profile.id`，同时返回期望类型和实际类型。 5. 禁止将无法确认的整数静默转换为 `float64` 后继续调用。 **验收** - 输入 `9223372036854775807` 作为 long，provider 收到未失真的 long 表示；超范围输入在 RPC 发出前失败。 - 嵌套对象缺少必填字段或 enum 值非法时，UI 显示具体字段路径和错误原因。 - 两个同名重载方法使用不同 signature 时，Admin 只允许 metadata 对应的参数组合。 ### 4. 展示 typed result 与 Java GenericException **问题** Admin 当前将 RPC 失败统一包装为 `InternalError/generic invoke failed...`，用户看不到 Java 业务异常 class。dubbo-go 应复用 #3167 已完成的 `GenericException`/`InvokeWithType` 能力，不复制 Hessian2 底层结构。 **涉及文件** | 功能 | 文件 | |---|---| | 显示结果、目标类型、异常 class/message 和错误类别 | `ui-vue3/src/views/resources/services/tabs/debug.vue` | | 在现有响应模型中承载结果及结构化异常信息 | `pkg/console/model/service.go` | | 提取 SDK 返回结果和错误，并映射为 Admin 响应 | `pkg/console/service/service_generic_invoke.go` | | 复用 InvokeWithType 及结果解码入口 | `filter/generic/service.go` | | 核对 mode-aware 返回处理 | `filter/generic/filter.go` | | 核对 provider 泛化结果与异常处理 | `filter/generic/service_filter.go` | **方案** 1. 成功响应区分普通泛化结果和 typed result，展示 JSON 结果及可用的目标类型。 2. 捕获并映射 `GenericException` 的 `ExceptionClass` 与 `ExceptionMessage`，例如 `com.example.UserNotFoundException` 和 `用户不存在`。 3. timeout、业务异常、序列化错误、参数校验错误使用不同稳定 error type；详细底层错误同时保留日志。 4. 若当前依赖版本没有公共 `filter/generic.GenericException` 入口，则提供 `type GenericException = hessian2.GenericException`，并用 `errors.As` 验证；若依赖升级已提供入口，则直接使用并删除 alias 方案。 **验收** - Java provider 抛出 `UserNotFoundException("用户不存在")`；API/UI 分别展示异常 class 和 message，而不是只显示统一 InternalError。 - provider 返回 typed result；UI 显示成功状态、结果值和类型信息。 - provider 超时或返回序列化错误；UI 显示对应 error type，且不伪装成业务异常。 ### 5. 建立真实跨仓库回归验证 **涉及文件** | 功能 | 文件 | |---|---| | 识别 UI mock 边界；不作为真实 RPC 验证证据 | `ui-vue3/src/mocks/handlers/service.ts` | | 真实 Admin 到 provider 调用链的验证入口 | `pkg/console/service/service_generic_invoke.go` | | 参数转换及错误边界的回归验证对象 | `pkg/console/service/service_generic_invoke_decode.go` | | Admin 开发环境及 discovery/engine/store 配置参考 | `docs/server-develop.md` | | Triple non-IDL unary 互操作验证对象 | `protocol/triple/triple_invoker.go` | **方案** 建立可重放的 E2E 场景，不以 UI mock 或 dubbo-go 单元测试替代 Admin↔provider 验证。最小组合如下： | Provider | 协议 | 覆盖 | |---|---|---| | Java | Dubbo | Map/Gson/Bean/Protobuf-JSON（provider 支持时） | | Go | Dubbo | Map/Gson/Bean/Protobuf-JSON（provider 支持时） | | Java | Triple | 支持 mode；non-IDL 仅 unary | | Go | Triple | 支持 mode；non-IDL 仅 unary | 每组覆盖基础参数、嵌套对象、数组、重载、attachments、timeout、业务异常和序列化错误。记录 HTTP 请求、实际 generic mode、wire 参数、返回 JSON 或明确错误。 **验收** - 每个 provider/协议/mode 组合有可重放请求和结果记录。 - `ui-vue3/src/mocks/handlers/service.ts` 只用于 UI mock 验证，不计入真实互操作通过。 - 配置 discovery/engine/store 后，Go Admin 能调用可发现的 Java 和 Go provider；未具备环境时必须明确标注 E2E 未执行。 ## 文件与负责人 | 模块 | 负责人 | |---|---| | 在 Admin 请求中明确泛化模式和序列化方式 | - | | 固定请求 wire 格式与 API 校验 | - | | 按 provider metadata 解码参数，禁止静默类型损失 |-| | 展示 typed result 与 Java GenericException | -| | 建立真实跨仓库回归验证 |- | -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
