EF Core Cosmos Provider 中空ID查询条件被忽略的问题解析

问题背景

在使用Entity Framework Core的Cosmos DB提供程序时，开发人员发现了一个特殊的行为：当查询条件中包含x.Id == null这样的表达式时，EF Core会完全忽略这个条件，而不是像预期那样抛出异常或返回空结果。

问题重现

考虑以下典型场景：

string userId = null; // 由于其他bug导致ID意外为null
var user = await context.Items.Where(x => x.Id == userId).SingleAsync();

在这种情况下，EF Core Cosmos提供程序会直接跳过x.Id == userId这个条件，导致查询可能返回意外的结果。这与开发人员对LINQ查询的预期行为不符——通常期望查询要么返回匹配结果，要么抛出异常。

技术原理分析

这个问题与Cosmos DB的特殊设计有关，特别是当ID属性同时被配置为分区键时。在EF Core 8.0版本中，当满足以下条件时会出现此问题：

1. 实体属性被同时标记为ID和分区键
2. 查询条件中对该属性进行null值比较
3. 使用EF Core 8.0或更早版本

问题的本质在于查询转换阶段，EF Core Cosmos提供程序在处理同时作为分区键的ID属性时，未能正确处理null值比较条件。

解决方案与修复情况

这个问题已经在EF Core 9.0版本中得到修复。在9.0版本中：

1. 当ID和分区键都为null时，查询会被正确转换为Cosmos DB的点读操作(ReadItem)
2. 系统会正确传递null值作为查询参数
3. 当没有匹配项时会抛出InvalidOperationException异常，符合LINQ的SingleAsync方法的行为预期

开发者建议

对于遇到此问题的开发者，我们建议：

1. 升级到EF Core 9.0：这是最直接的解决方案，9.0版本已经完整修复了这个问题

2. 临时解决方案：如果暂时无法升级，可以在应用层添加显式检查：

   if (userId == null)
   {
       throw new ArgumentNullException(nameof(userId));
   }
   

3. 设计建议：

   • 尽量避免使用null作为ID值
   • 启用C#的可空引用类型(NRT)功能，可以在编译期捕获潜在的空引用问题
   • 考虑将ID属性设计为非可空类型

总结

这个问题展示了数据库提供程序特定行为与开发者预期之间的差异。EF Core团队在9.0版本中通过重构ID和分区键处理逻辑解决了这个问题，使得查询行为更加符合LINQ语义。对于仍在使用8.0版本的开发者，建议通过应用层验证来避免潜在问题，并计划升级到9.0版本以获得更稳定的行为。