Race condition in valueChanges()

[DraviaVemal]

Race condition happening in valueChanges() of doc [subscribe keeps firing with no data change in document].
The issue is happening in angular prod build, Dev build works fine.
Tested downgrading the package to AngularFire v6.0.5, the issue is not replicable.

Version info

**Angular: 10.2.3

**Firebase:8.2.1

**AngularFire:6.1.4

How to reproduce these conditions

sample code

this.getString()
      .pipe(switchMap((docName) => {
        if (docName !== '') {
          return this.angularFireStore.collection(eColName.PublicCol).doc(docName).valueChanges();
        }
      })).pipe(filter(val => val !== null))
      .subscribe(
        (publicDocData) => {
          this.publicData.next(publicDocDataa);
        }
      );

Debug output

NA

Expected behavior

Subscribe method should execute on start and on doc change

Actual behavior

Subscribe method executed like while loop without any end

Details I'm not sure is relevant:
Tsconfig:
"module": "es2020",
"target": "ES2015",
Angular dev and Prod build diff.
optimization & buildOptimizer are true in prod rest are same

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[timofei-iatsenko]

Confirming, have the same behaviour after latest updates but not only with valueChanges(). All subscription methods fires randomly in time (it's clearly visible because we have a user notification which appears on changes, but it appears when no changes happend)

[DraviaVemal]

Tested with angular 11 as well the issue exists.

Version info
**Angular: 11.0.5

**Firebase:8.2.1

**AngularFire:6.1.4

[jamesdaniels]

I bet this has to do with metadata changes, I fixed a bug which meant they weren't getting emitted on snapshotChanges... perhaps I need to add a distinctUntilChanged(... /* deep eq check */) on the return from valueChanges(). Honestly I usually use snapshotChanges myself so I'm use to seeing all these extra emissions. I'll look into this.

FWIW that might be a work around for now.

[pixelbits-mk]

Getting the same issue... is this being fixed?

[MarkWestside]

Not completely sure if it is related, but I have the same issue. Running @angular/[email protected] in Angular 9 is fine but @angular/[email protected] with Angular 11 fires a lot of network requests that slow down the site.

For example, when I log out using AngularFireAuth.signOut(), I have 4 network requests with 6.0.2 and 40 (!) with 6.1.4.
Same if I add distinctUntilChanged().

[jamesdaniels]

Closing as some of this should be addressed in v7, others are just how the library works, developers should use distinctUntilChanged to reduce down change detection fires to changes that they care about