Apollo Client中AutoCleanedWeakCache在fakeAsync测试中的问题分析

问题背景

在Angular 17项目中，当开发者使用@angular/core/testing中的fakeAsync区域运行Jest测试时，会遇到一个关于定时器的错误提示："Error: 2 timer(s) still in the queue"。这个问题出现在使用Apollo Client 3.9.0及以上版本时，而回退到3.8.10版本则可以避免。

技术原理分析

问题的根源在于Apollo Client 3.9.0引入的AutoCleanedWeakCache机制。这是一个自动清理的弱引用缓存实现，主要目的是优化缓存清理的性能。其核心实现逻辑如下：

1. 使用WeakSet跟踪已安排清理的缓存实例
2. 当向缓存添加新条目时，会调用schedule函数安排清理
3. schedule函数会设置一个100ms的定时器来执行实际清理操作

var scheduledCleanup = new WeakSet();
function schedule(cache) {
    if (!scheduledCleanup.has(cache)) {
        scheduledCleanup.add(cache);
        setTimeout(function () {
            cache.clean();
            scheduledCleanup.delete(cache);
        }, 100);
    }
}

问题本质

在Angular的fakeAsync测试环境中，所有异步操作都需要被显式控制或刷新。AutoCleanedWeakCache自动设置的定时器成为了测试环境中的"泄漏"定时器，导致测试框架检测到未处理的异步操作而报错。

解决方案演进

Apollo Client团队对此问题提供了两个层面的解决方案：

1. 临时解决方案：在测试代码中手动调用flush(1)或flush(2)来显式处理这些定时器

2. 根本解决方案：优化AutoCleanedWeakCache的实现，使其只在缓存确实需要清理时才安排定时任务，而不是每次添加条目都安排。这通过PR#11792实现，并已提供测试版本供验证

技术启示

这个问题给我们几个重要的技术启示：

1. 库的设计需要考虑测试环境的特殊性，特别是涉及异步操作时
2. 性能优化机制可能会与测试工具产生冲突，需要平衡两者
3. 弱引用缓存的使用需要谨慎处理清理时机，避免不必要的操作

最佳实践建议

对于开发者而言，在处理类似问题时可以：

1. 在测试中合理使用fakeAsync和flush的组合
2. 关注库的更新日志，特别是涉及核心机制的变更
3. 在遇到测试问题时，考虑是否是测试环境与生产环境的差异导致
4. 对于性能优化机制，理解其工作原理有助于更好地使用和调试

Apollo Client团队对此问题的快速响应和解决方案体现了对开发者体验的重视，这也是开源社区协作的典范。