当 Argo Rollouts 仪表盘的命名空间下拉框消失时
内容提要
Argo Rollouts 仪表盘的命名空间下拉框失效，排查发现 RBAC、网络、版本均正常。真正原因是集群中某个 Rollout 的 resources.limits 被误写成字符串而非 map，导致 client-go 整体解码集群级列表失败。代码中 if err == nil 静默吞掉错误，接口仍返回 200 但 availableNamespaces 为空。建议在 CI 或 ArgoCD 校验阶段拦截此类 YAML 类型错误。
延伸解读
静默错误如何掩盖真实问题
文章指出，代码中的 `if err == nil` 会吞掉列表解码错误，导致接口仍返回 200 但 `availableNamespaces` 为空。这种设计让前端表现为下拉框禁用，而非报错，极大增加了排查难度。读者应意识到，HTTP 200 并不代表逻辑正确，空数组也可能是错误被静默处理的结果。在类似场景中，需主动检查后端日志或直接调用其他端点验证。
单个坏对象为何拖垮整个列表
client-go 的 typed client 在解码集群级列表时是整体进行的，只要有一个对象的字段类型错误（如 `resources.limits` 被写成字符串而非 map），整个列表解码就会失败。这解释了为何按命名空间查询正常，而全局列表却为空。这种“全有或全无”的解码机制意味着，一个不起眼的 YAML 类型错误足以让依赖列表的接口失效，影响范围远超单个对象。
排查顺序：从权限到其他端点错误
作者先怀疑 RBAC、网络协议和版本，逐一排除后，通过按命名空间查询的端点发现了具体的解码错误信息，才定位到问题对象。这提示我们，当常规检查（权限、网络、版本）都正常时，应转而查看其他相关端点的错误输出，往往能快速锁定根因。此外，直接使用 `kubectl get rollouts -A -o json` 检查所有对象的字段类型，也是有效的验证手段。
设计局限与预防建议
文章还提到，`availableNamespaces` 仅包含部署了 Rollout 的命名空间，而非集群全部命名空间，因此即使修复 bug，下拉框也不会显示所有命名空间。要查看全部命名空间仍需使用 `kubectl get ns`。作者建议在 CI 或 ArgoCD 校验阶段拦截此类 YAML 类型错误，避免坏对象进入集群。这提醒读者，在流水线中加入 schema 校验能有效预防类似问题。
Q&A
Argo Rollouts 仪表盘的命名空间下拉框变成灰色不可选，可能是什么原因？
根本原因是集群中某个 Rollout 的 resources.limits 字段被错误地写成了字符串（如 "memory:6Gi"），而不是正确的 map 格式（如 memory: 6Gi）。这导致 client-go 在解码集群级 Rollout 列表时整体失败，接口返回的 availableNamespaces 为空，前端因此将下拉框渲染为禁用状态。
为什么一个 Rollout 的 YAML 类型错误会导致整个命名空间列表消失？
因为 Argo Rollouts 服务端通过 client-go 的 typed client 一次性解码整个集群的 Rollout 列表。只要其中一个对象的字段类型错误（如 limits 应为 map 却写成 string），整个列表解码就会失败，err 不为 nil，循环不会执行，availableNamespaces 保持为空。而代码中的 if err == nil 静默吞掉了错误，接口仍返回 200，但列表为空。
如何确认是哪个 Rollout 的 resources 字段写错了？
可以逐个命名空间调用 /api/v1/rollouts/{namespace}/info 接口，当某个命名空间返回类似 "json: cannot unmarshal string into Go struct field ... resources.limits of type v1.ResourceList" 的错误时，说明该命名空间下有 Rollout 的 resources.limits 类型错误。也可以用 kubectl get rollouts -A -o json 导出所有 Rollout，检查每个 template 中的 resources 字段，找到 limits 值为字符串的那个。
为什么 /api/v1/namespace 接口返回 200 但 availableNamespaces 为空？
因为服务端代码在调用集群级 List 后，用 if err == nil 判断是否成功，但解码失败时 err 不为 nil，循环被跳过，availableNamespaces 保持为空切片。由于 protobuf 转 JSON 时会丢弃空 repeated 字段，所以响应中该字段消失，前端得到空数组，下拉框变为禁用。接口本身没有返回错误状态码，因此仍是 200。
Argo Rollouts 仪表盘的 availableNamespaces 包含所有命名空间吗？
不是。availableNamespaces 只包含部署了 Rollout 资源的命名空间，而不是集群中的所有命名空间。即使修复了上述 bug，下拉框也只会显示有 Rollout 的命名空间。如果需要查看所有命名空间，应使用 kubectl get ns。
如何避免类似的 YAML 类型错误导致仪表盘故障？
建议在 CI 流程或 ArgoCD 的校验阶段拦截此类 YAML 类型错误，确保 resources.limits 等字段使用正确的 map 格式，而不是字符串。这样可以在对象进入集群前就发现问题，避免影响仪表盘等依赖集群级列表的功能。
