我非常理解你的困惑——碰到这种模糊的RPC错误，而不是直接告诉你“类型不匹配”，确实会让人摸不着头脑，我之前用Milvus 2.5做数组字段查询的时候也踩过类似的坑。

为什么会出现这种情况？ #

这个问题的核心在于Milvus 2.5版本的查询校验链路不够完善：

• 首先，PyMilvus客户端在发送查询请求前，并没有对json_contains_all的数组参数做严格的类型一致性校验——它没有检查你传入的数组字面量里的元素类型是否统一，也没有和字段定义的ARRAY<FLOAT>做匹配校验，就直接把请求转发给了后端的QueryNode。
• 当QueryNode接收到请求后，在底层执行匹配逻辑时，发现混合了int和float类型的数组无法和定义为FLOAT的数组字段做匹配，但是这个错误没有被上层的错误处理模块捕获并转化为用户友好的提示，而是直接抛出了最底层的RPC执行异常，也就是你看到的MilvusException: fail to Query on QueryNode。

这是预期行为吗？ #

明确说：这不是Milvus设计时的预期行为，而是当前版本的一个已知的用户体验缺陷。Milvus的开发团队其实也意识到了这类前端校验缺失、错误信息不友好的问题，社区里也有不少用户反馈过类似的场景。

临时解决办法 #

在官方优化这个问题之前，你可以通过以下方式避免踩坑：

• 手动确保查询用的数组字面量元素类型统一，并且匹配字段定义的类型：比如把[2, 4.0]改成[2.0, 4.0]，全用float类型就不会触发这个错误。
• 如果你的查询参数是动态生成的（比如从其他数据源获取的数组），可以在传入Milvus之前，先把所有元素强制转换为float类型，比如用Python的列表推导式[float(num) for num in your_array]处理后再传入查询。

后续Milvus的新版本应该会完善这部分的校验逻辑，把类型检查提前到客户端或者查询解析的早期阶段，直接给出“数组元素类型必须统一，且与字段定义的FLOAT类型匹配”这类明确提示，不用再让用户去猜底层RPC错误的原因。