seeing Listen stream 400s

[benrglassman]

seeing Listen stream 400s despite
No listeners
Long polling enabled
Dev flags set
SDK v11.7.1
Firebase should not be triggering Listen/channel endpoints.

✅ I've done	📉 Yet Firestore still
Removed all listeners	Tries to open Listen/WebChannel
Forced long polling	Uses WebChannel anyway
Upgraded SDK	Still broken
Removed perf/analytics	No change
Verified config	SDK violates it internally

My environment:
Firebase SDK version: 11.7.1
Firebase product(s) used: Firestore, Auth
Platform: Web (Vite + React, tested in Safari & Chrome)
Browser: Safari 17.4.1 (macOS), also Chrome latest
Framework: Vite + React (TS)

We are seeing repeated WebChannelConnection errors for Listen streams with status code 400, even though:

We have explicitly forced Firestore to use long polling
We do not use onSnapshot() or any real-time listeners anywhere in our codebase
We set all flags globally before Firebase is imported
We disabled Performance Monitoring, Analytics, and Remote Config
We confirmed that only a single Firestore instance exists
We are only using getDoc, getDocs, setDoc, and addDoc
We're using Firebase SDK 11.7.1 and the modular API only
We see "Initializing Firestore with long polling" and the correct settings() logged
Despite all of this, Firestore still attempts to open Listen streams via WebChannel, which fail with 400 errors and prevent our dev environment from functioning.

Steps to reproduce
Set up a Vite + React app with Firebase SDK v11.7.1
In main.tsx, before any Firebase imports, add:
window['FIREBASE_DEFAULTS'] = {
config: { /* your config */ },
settings: {
firestore: {
experimentalForceLongPolling: true,
cacheSizeBytes: 1048576
}
}
};
Disable Analytics, Performance, and persistence
Use only getDocs() / setDoc() calls in code
Log Firestore settings, and confirm only a single db instance
Run the app and check browser network tab or logs
Expected behavior
Firestore should respect experimentalForceLongPolling: true and never attempt WebChannel Listen streams unless we explicitly call onSnapshot() (which we do not).

Actual behavior
Even with the above setup:

Firestore still attempts to hit:
https://firestore.googleapis.com/google.firestore.v1.Firestore/Listen/channel...
This results in:
WebChannelConnection – RPC 'Listen' stream transport errored – status 400
Our app hangs because no data is returned, and the listen stream silently breaks the data load pipeline
We confirmed that no onSnapshot() is called, and that the Firestore instance is correctly configured
Additional context
We have manually verified that no third-party libraries or hooks (like useCollectionData) are present
We have patched onSnapshot globally in dev and confirmed it never runs
We suspect this may be caused by Firestore’s internal caching, rehydration, or optimistic write behavior
Request
Please confirm whether:

Firestore SDK internally triggers Listen streams even when only getDocs() is used
experimentalForceLongPolling is sufficient to prevent any WebChannel transport in all cases
There is any way to fully prevent all real-time or streaming behavior in dev
We’re looking for a definitive answer or workaround to disable all WebChannel activity in non-production environments.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[MarkDuckworth]

This may be a duplicate with a known fix. Please take a look at this to see if it helps fix the issue: #8864 (comment)

[benrglassman]

the issue persists- I reverted to a (default) named firestore db

[benrglassman]

nvm