Apollo Client 中 useSuspenseQuery 的 fetchMore 错误处理问题分析

问题背景

在 React 应用中，Apollo Client 的 useSuspenseQuery 钩子与 Suspense 结合使用时，开发者可能会遇到一个棘手的问题：当 fetchMore 操作失败时，相关的 Promise 会永远保持 pending 状态，导致 ErrorBoundary 无法捕获错误。

问题现象

当使用 useSuspenseQuery 进行数据获取时，如果后续的 fetchMore 请求失败（无论是网络错误还是变量错误），会出现以下情况：

1. 组件会一直处于挂起状态，UI 被 Suspense 的 fallback 内容占据
2. 错误不会被 ErrorBoundary 捕获
3. 应用状态陷入不可恢复的等待状态

技术原理分析

这个问题的根源在于 Apollo Client 内部 QueryReference 类的实现机制：

1. 双 Promise 机制：useSuspenseQuery 内部维护了两个 Promise - 一个是返回给 Suspense 的 this.promise，另一个是实际数据请求的 returnedPromise

2. 错误处理缺失：当 returnedPromise 被拒绝时，虽然捕获了错误，但没有将错误传播到 this.promise

3. 状态同步问题：this.promise 在请求失败后仍然保持 pending 状态，导致 Suspense 持续等待

解决方案

社区贡献者发现了一个有效的修复方案：

1. 在 returnedPromise 的 catch 处理中，检查 this.promise 的状态
2. 如果 this.promise 仍处于 pending 状态，则调用 handleError 方法
3. 这样可以将错误正确传播到 Suspense 系统

最佳实践建议

对于使用 Apollo Client 的开发者，在处理分页加载时应注意：

1. 考虑为 fetchMore 操作添加独立的错误处理
2. 在关键数据加载处添加额外的错误边界
3. 监控长时间处于 pending 状态的查询
4. 测试各种网络错误场景下的应用行为

总结

Apollo Client 作为流行的 GraphQL 客户端，其 Suspense 集成功能仍在不断完善中。这个问题的发现和修复展示了开源社区协作的价值，也提醒我们在使用前沿技术时需要更全面的测试。开发者应当关注这类边界情况，确保应用在各种异常场景下都能优雅降级。