Cht-core: PouchDB's server side checkpoint files always have the same name for the same user

[SCdF]

@alxndrsn and I were both trying to start medic for the same user on different devices. This resulted in us writing to the same server side _local file, which in turn results in 409s.

We should confirm this is the case with better testing.

If our understanding of the issue is true though, then a user cannot have two devices safely: as their check pointing will fight each other, which in turn could cause other issues (ie perhaps starting again from seq 0, perhaps getting into writing fights and never finishing etc).

cc. @garethbowen

[alxndrsn]

This may also mean that logging in to a user's account for debugging may ruin their synch status.

[alxndrsn]

Generated at https://github.com/pouchdb/pouchdb/blob/master/packages/node_modules/pouchdb-generate-replication-id/src/index.js

Looks like we'd want to patch it to use some kind of unique browser fingerprint, which isn't going to change over time.

Or perhaps we could generate a more random local database name, and store it at a predictable location.

E.g.

const metaDb = new PouchDB(`medic-meta-${username}`);
metaDb.get('real-db-name')
  .then(doc => loadRealDb(doc.name))
  .catch(err => {
    if(is404(err)) {
      return generateNewRealDbName()
        .then(storeRealDbName)
        .then(loadRealDb);
    } else throw err;
  });

[garethbowen]

It's definitely worth raising an issue with pouch. IDK what the unique browser fingerprint would be but maybe they could randomly generate a salt and store that somewhere...

NB: another workaround for us is to disable server side checkpointing - ie: #4120 and #4146

[alxndrsn]

db = angular.element(document.body).injector().get('DB')();
db.id().then(id => console.log(id, db.name, '<- why would those two be the same?'));

This looks like an issue with our setup, rather than pouch. Probably angular-pouchdb.

[SCdF]

For context:

new PouchDB('medic-user-fredrickot').id().then(console.log).error(console.error)
inbox.js:66 9E6C3413-E78B-4D22-BD00-E072F2090C75
new PouchDB('medic-user-fredrickot').name
"medic-user-fredrickot"
db = angular.element(document.body).injector().get('DB')();
db.id().then(id => console.log(id, db.name, '<- why would those two be the same?'));
inbox.js:66 medic-user-fredrickot medic-user-fredrickot <- why would those two be the same?

So what should be a UUID is for us the name of the document. Something, (us, worker-pouch or angular-pouch) must be doing this.

[alxndrsn]

Known issue: https://github.com/pouchdb-community/worker-pouch/issues/34

Waiting for PR to be merged, and subsequent release.

[garethbowen]

It's been waiting for almost a year now - it may need a hurry along...

[garethbowen]

I've got GH and npm permissions so I'll get this released for our 2.15.0 release.

[garethbowen]

When this fix is released check what happens to existing users if their server checkpoint IDs change.

[garethbowen]

We've dropped worker-pouch so this should now be fixed. I'll release a new worker-pouch so if we go back to using it this bug won't come back and also so everyone else gets the patch. But for now, we can just AT that this is no longer the case!

[alxndrsn]

@garethbowen is there anything blocking the new worker-pouch release? I know we're not planning to use it, but maybe worth doing now so we don't get bitten again in future?

[garethbowen]

It's definitely on my todo list. Hopefully in the next few days...

[ngaruko]

Any clue on how to AT this issue @SCdF @alxndrsn @alxndrsn ? Thanks

[SCdF]

@ngaruko essentially the bug is that multiple instances of the same user were writing to the same _local doc on the server. If you watch the network tab while replicating you will see PouchDB writes to _local/randomstring on the server a lot. This is it writing checkpointing indicating what it has replicated up to that server.

You want to make sure that different instances of the same user are writing to different _local docs. So one way would be to load a user in Chrome and Firefox, or Chrome and the android wrapper, and observe that they write to different docs.

If you're not completely sure about this I'd suggest you prepare this testing using a version where this is not fixed, so you can see the failure occurring.