Polly库中ResilienceProperties对null值处理的缺陷分析

问题背景

在Polly这个.NET弹性与瞬时故障处理库的8.4.1版本中，ResilienceProperties类在处理null值时存在一个关键缺陷。这个类用于存储和管理弹性策略执行过程中的各种属性值，但在特定场景下会出现不符合预期的行为。

问题现象

当开发者尝试存储和检索null值时，ResilienceProperties的两个核心方法表现异常：

1. TryGetValue方法：当查询的键对应的值为null时，该方法错误地返回false，表示键不存在，而实际上键是存在的，只是值为null。

2. GetValue方法：同样情况下，该方法没有返回实际的null值，而是返回了调用者提供的默认值，这与方法的语义不符。

代码示例

// 创建属性键和属性集合
var key = new ResiliencePropertyKey<string?>("dummy");
var props = new ResilienceProperties();

// 显式设置null值
props.Set(key, null);

// 问题1：TryGetValue错误地返回false
bool exists = props.TryGetValue(key, out var val); // exists为false，val为null

// 问题2：GetValue返回默认值而非实际的null
string? result = props.GetValue(key, "default"); // 返回"default"而非null

技术分析

这个问题的根本原因在于ResilienceProperties内部可能使用了类似Dictionary的数据结构，而判断键是否存在时可能直接使用了值是否为null作为判断条件。这种实现方式在C#中是一个常见的陷阱，因为Dictionary允许存储null值。

正确的实现应该：

1. 区分"键不存在"和"键存在但值为null"这两种情况
2. 对于TryGetValue，只要键存在就应该返回true，无论值是否为null
3. 对于GetValue，应该返回实际存储的值，即使它是null

影响范围

这个问题会影响所有使用ResilienceProperties存储可能为null值的场景，特别是在：

• 自定义弹性策略实现中
• 策略执行上下文的数据传递中
• 需要明确区分"无值"和"null值"的业务逻辑中

解决方案

Polly团队已经通过PR修复了这个问题。修复的核心思想是：

1. 确保内部数据结构正确跟踪所有已设置的键
2. 将键存在性与值是否为null解耦
3. 保持API的明确语义

修复后，上述示例代码将产生符合预期的结果：

• TryGetValue返回true，表示键存在
• GetValue返回null，反映实际存储的值

最佳实践

开发者在使用ResilienceProperties时应注意：

1. 明确区分"值不存在"和"值为null"的业务语义
2. 对于可能为null的值，考虑使用Nullable类型明确表示
3. 在升级Polly版本时，注意这个行为变化可能影响现有代码

这个修复体现了Polly团队对API一致性和正确性的重视，确保了库在各种边缘情况下都能提供可靠的行为。