Firebase Admin Node 在 Bun 运行时中的 Firestore 查询异常问题分析

问题背景

在 Firebase Admin Node SDK 与 Bun 运行时的组合使用场景中，开发者报告了一个关于 Firestore 查询结果不一致的问题。具体表现为：当使用 Bun 运行时执行 Firestore 查询时，返回的记录数量会出现随机变化的情况，而同样的代码在 Node.js 环境下则能正常工作。

问题表现

开发者在使用 Bun v1.1.13 运行时环境时发现：

1. 对包含约200条记录的 users 集合执行查询时，返回的记录数量随机变化
2. 无论是否添加 orderBy 和 limit 子句，问题都会出现
3. 在 Node.js v16 和 v21 环境下，相同代码能正常工作
4. 问题发生时没有抛出任何错误或警告信息

问题复现

通过简化测试脚本可以稳定复现该问题：

// 初始化代码
const credential = applicationDefault();
const firebaseApp = initializeApp({ credential });
const db = getFirestore(firebaseApp);

// 查询代码
const collectionRef = db.collection("users");
for (let i=0; i<10; i++) {
  const snapshot = await collectionRef.get(); 
  console.log(`Query returned ${snapshot.size} documents`);
}

在 Bun 环境下执行时，输出结果类似：

Query returned 168 documents
Query returned 176 documents
Query returned 196 documents
Query returned 168 documents
Query returned 200 documents
Query returned 185 documents
// 后续查询结果继续随机变化

问题根源分析

经过技术团队调查，发现问题可能源于以下几个方面：

1. 运行时兼容性问题：Firebase Admin SDK 及其底层依赖库（如 gax-nodejs）主要针对 Node.js 运行时设计和优化，对 Bun 运行时的支持属于实验性质。

2. HTTP/2 流处理差异：Bun 的 node:http2 模块实现与 Node.js 存在细微差异，可能导致 GRPC 流在传输过程中被提前终止，造成数据截断。

3. 异步回调时序问题：Node.js 的流处理回调机制与 Bun 的实现可能存在时序差异，导致"end"事件被过早触发。

解决方案

临时解决方案

在 Bun 官方修复该问题前，可以采用以下临时解决方案：

// 使用 REST 替代 GRPC
import { initializeFirestore } from "firebase-admin/firestore";
const db = initializeFirestore(firebaseApp, { preferRest: true });

这种方法通过强制使用 REST 协议而非默认的 GRPC 协议来规避问题。但需要注意：

1. 不支持实时监听功能（onSnapshot）
2. 性能可能略低于 GRPC 协议

长期解决方案

1. 升级 Bun 运行时：最新版本的 Bun（v1.1.13 之后）已经修复了相关 HTTP/2 模块的问题。

2. 等待官方支持：关注 Firebase 对多运行时的官方支持计划。

最佳实践建议

对于生产环境使用，建议：

1. 优先使用 Node.js 运行时以获得最佳兼容性
2. 如需使用 Bun 运行时：
   • 确保使用最新版本
   • 考虑启用 REST 协议
   • 充分测试所有 Firestore 操作
3. 避免在关键业务逻辑中混用不同运行时

技术启示

这个案例展示了跨运行时开发中可能遇到的微妙兼容性问题。开发者需要注意：

1. 底层网络协议实现的差异可能导致高层 API 行为不一致
2. 新兴运行时虽然兼容 Node.js API，但在实现细节上可能存在差异
3. 对于数据库操作等关键功能，充分的跨环境测试必不可少

随着 JavaScript 生态中多运行时趋势的发展，这类兼容性问题可能会更加常见，开发者需要建立相应的测试和应对策略。