ngxs-labs/firestore-plugin

Malformed data issue

santekotturi opened this issue · 3 comments

I'm using collection$ for a number of different subcollections on a document. Everything was working fine for weeks. Then some malformed documents got inserted into some subcollections.

My collection$ calls get setup like this:

 this.ngxsFirestoreConnect.connect(FetchBulletins, {
      to: () => this.bulletinSvc.collection$(),
    });

...

 this.ngxsFirestoreConnect.connect(FetchHangouts, {
      to: () => this.hangoutSvc.collection$(),
    });

... etc etc

These actions are dispatched and then StreamEmitted handles incoming data.

The main issue is that this caused really weird behavior using this plugin: I started to receive data from other subcollections from the StreamEmitted action. But they weren't the full docs, just the {id: string} field of these docs.

Truly bizarre, I deleted the malformed docs and now everything is fine again.

Question: is there anything in this lib that would have cached data and returned it? I think it's interesting that id field was passed, it's the idField that I provide in each subcollection NgxsFirestore service. I tried looking through the source code but couldn't find anything the stuck out to me. Maybe there's some "retry" method I missed that could be causing this?

I'm going to write some better assertion checking for my toFirestore converters to try and prevent any malformed data from reaching the db but this def threw me for a bizarre loop.

hmmm, there's nothing in the library that performs caching, firestore may be doing that... i've seen that behavior in my apps some times, most of the time, the first emission is cached and might not have the complete results documents, that's what have happened to me...

I've noticed that as well, it's streaming documents, the first emission contains say 10 docs, the next emissions contains 26 etc. Usually by the 2nd of 3rd emission the entire query result is returned. I've used debounce to flatten the first couple emissions from time to time when this can cause visual flickering as ngFor's are rendered. This is different though, this was returning docs from a different collection, not partial results from 1 query.

If I can figure out the root of it, I'll post it. Until then, it'll remain a mystery 🧞‍♂️

Following up: I don't know what was causing it. I added an assertion backend function that deletes any newly created doc that doesn't have certain fields. It's a hack of a workaround but it works and should probably exist as a fail safe. I was writing read_receipts for messages based on scroll position rapidly and during init, the ID of the doc that needed read_receipts wasnt available yet so it was creating docs which were then being passed in through StreamEmitted and breaking the fromFirestore adapter. From there I'm not sure how data from one collection was getting stored in the state of another collection...