Elasticsearch返回带双引号数字导致Nest反序列化崩溃

问题原因 #

稳定运行的ES集群不会主动修改数值字段的返回格式，返回值带双引号本质是你查询命中的某些分片里，目标字段实际是字符串类型，和你在Kibana里看到的long映射不一致，最常见的触发场景：

• 索引滚动/重建时映射漂移：如果你的业务用了ES的滚动索引、ILM生命周期管理，新生成的索引如果没有匹配到正确的索引模板，ES动态映射会根据首条写入的字段值自动推断类型——如果首条写入的该字段值是字符串格式（比如上游业务临时传了字符串类型的数字），新索引里该字段就会被自动映射为keyword/text类型，查询命中这类分片时，返回的字段值自然是带双引号的字符串。
• 多字段映射误命中：如果该字段配置了多字段（比如主字段是long类型，同时配置了.keyword子字段用于精确匹配），查询时如果字段名写错、或者聚合/排序字段误指向了keyword子字段，也会返回字符串格式的值。

不要仅依赖Kibana索引模式页展示的映射判断字段类型，Kibana的索引模式是静态配置的，不会实时同步所有历史索引、新生成索引的实际映射变化。

排查步骤 #

• 先获取ES服务端版本，直接用现有NEST客户端调用即可，不需要额外工具：

  var infoResponse = client.RootNodeInfo();
  var serverVersion = infoResponse.Version.Number;
  

• 直接调用ES接口检查所有命中索引的实际字段映射：

  GET 你的查询目标索引通配符*/_mapping/field/报错的字段名
  

  检查返回结果中每个索引对该字段的类型定义，只要存在任意一个索引把该字段定义为keyword/text类型，就会出现随机解析报错的问题。
• 回溯近期操作：重点检查近1-2周是否有索引模板修改、ILM策略调整、重建索引、上游业务数据格式变更的操作，这类操作是映射漂移的核心诱因。

修复方案 #

• 根治方案：统一所有索引的字段映射，对于已经生成的类型错误的索引，用_reindex接口把数据迁移到映射正确的新索引，同时修正索引模板，保证后续滚动生成的新索引字段类型正确。
• 临时兼容方案：如果短时间内无法统一索引侧映射，可以给NEST客户端配置自定义格式化器，兼容字符串格式的数字反序列化，不需要修改业务实体的int类型定义：
  1. 定义自定义格式化器：

     public class FlexibleIntFormatter : IJsonFormatter<int>
     {
         public int Deserialize(ref JsonReader reader, IJsonFormatterResolver formatterResolver)
         {
             var token = reader.GetCurrentJsonToken();
             return token switch
             {
                 JsonToken.Number => reader.ReadInt32(),
                 JsonToken.String => int.Parse(reader.ReadString()),
                 _ => throw new JsonParsingException($"无法将{token}类型转换为int")
             };
         }
     
         public void Serialize(ref JsonWriter writer, int value, IJsonFormatterResolver formatterResolver)
         {
             writer.WriteInt32(value);
         }
     }
     

  2. 在报错的实体属性上标注特性启用格式化器：

     public class YourBusinessEntity
     {
         [JsonFormatter(typeof(FlexibleIntFormatter))]
         public int YourErrorField { get; set; }
         // 其他属性保持不变
     }
     

内容的提问来源于stack exchange，提问作者bkqc