Before gliding pass this bug you may want to stop because this is going to happen.
So the PouchDB has done a bunch of work to make itself less likely to corrupt data but in certain app/phone crashing scenarios data can be corrupted. Imagine a phone running out of battery. Or the app getting into a bad state. If the wrong thing happens at the wrong time then the data on disk will be corrupted. If we are very lucky we will just lose some data. If we are not so lucky the DB will become corrupted and we will be done.
So this brings up several problems we haven't come close to addressing:
How do we detect when we have a corrupt db? My guess is that right now the app would just die horribly. Not a great user experience.
How do we recover from a corrupt db? I suppose we could tell the user to uninstall and re-install the app, not much fun there.
How do we deal with peers who don't know our db has lost some state or is totally corrupted? This is a really fun one to recover from. If we have just lost some data then our peers think we are farther ahead in the sequence of items than we are and we have no way to recover that lost data. Even better, the sequence ID we have recorded in the remote DB as being our last update point will, in fact, be wrong, so we will NEVER get those records back. Can you feel the joy?
Before gliding pass this bug you may want to stop because this is going to happen.
So the PouchDB has done a bunch of work to make itself less likely to corrupt data but in certain app/phone crashing scenarios data can be corrupted. Imagine a phone running out of battery. Or the app getting into a bad state. If the wrong thing happens at the wrong time then the data on disk will be corrupted. If we are very lucky we will just lose some data. If we are not so lucky the DB will become corrupted and we will be done.
So this brings up several problems we haven't come close to addressing: