google_cloud_firestore 0.5.5: ~2× higher latency under concurrent load after switch to a shared HTTP/2 connection #333

Title: google_cloud_firestore 0.5.5: ~2× higher latency under concurrent load since the switch to a shared HTTP/2 connection

Environment

• google_cloud_firestore 0.5.5, pulled in through firebase_admin_sdk 0.5.3 (^0.5.0); last good version: 0.5.4
• Dart 3.12.2, dart_frog 1.2.6 on Cloud Run (europe-west3)
• One global Firestore instance per container; container concurrency 25

Problem
0.5.5 pools all requests over shared HTTP/2 connections instead of opening an HTTP/1.1 connection per request. After a redeploy that picked up 0.5.5, our Firestore-heavy workloads became about 2× slower. We changed no code in the affected paths.

Requests that do only small reads also slow down whenever bulk reads run on the same instance. That suggests contention on the shared connection.

Suspected cause
All requests share one TCP connection, the flow-control windows may be small, and package:http2 does its framing in Dart on the same isolate as the application.

Reproduction

final db = FirebaseApp.initializeApp(/* ... */).firestore();
final sw = Stopwatch()..start();
await Future.wait(List.generate(20, (_) => db.collection('large_collection').get())); // 5k–20k docs each
print('${sw.elapsedMilliseconds} ms');

Run once with 0.5.4 and once with 0.5.5 (via dependency_overrides), then compare.

Questions

1. Can we switch back to the HTTP/1.1 transport, or configure the pool size and flow-control window?
2. Should a transport change like this ship as a patch release? Everyone on ^0.5.0 picks it up automatically.

Workaround

dependency_overrides:
  google_cloud_firestore: 0.5.4