pouchdb: Cannot handle 401 error during live replication

I would like any exceptional errors that happen during PouchDB<->CouchDB replication to notify my app to log the user out (since the problem is likely to be caused by stale login data or expired CouchDB credentials). This includes attempting to access a non-existent database, or 401 errors indicating incorrect credentials. I can use the paused event from the replicator to see errors that happen during the replication process, but there doesn’t seem to be a way to handle 401 Unauthorized errors that happen during replication. Try as I might, they always get reported as unhandled promise exceptions.

From the cursory glance at the source, it seems likely that the change handler’s error events do not get propagated to the replication handler’s listeners, and that the 401 error is happening from within the changes feed.

Is this a bug/oversight, or am I missing an event that I can handle?

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 4
Comments: 17 (7 by maintainers)

Commits related to this issue

(#5172) - Differentiate between validation and non-validation errors Up to now, all 401 and 403 error were treated the same, i.e. it was assumed that it may be connected to a result of a validation f... — committed to evidenceprime/pouchdb by anowak 8 years ago
(#5172) - Differentiate between validation and non-validation errors Up to now, all 401 and 403 error were treated the same, i.e. it was assumed that it may be connected to a result of a validation f... — committed to evidenceprime/pouchdb by anowak 8 years ago
(#5172) - Differentiate between validation and non-validation errors Up to now, all 401 and 403 error were treated the same, i.e. it was assumed that it may be connected to a result of a validation ... — committed to pouchdb/pouchdb by anowak 8 years ago
(#5172) - Differentiate between validation and non-validation errors Up to now, all 401 and 403 error were treated the same, i.e. it was assumed that it may be connected to a result of a validation ... — committed to evidenceprime/pouchdb by anowak 8 years ago

Most upvoted comments

Fixed in https://github.com/pouchdb/pouchdb/commit/0e14d2213cebe5798c0e34d5faab21b815cc6427

daleharvey on Jul 8, 2016

I’m having the same issue as @gillez on version 5.4.4.

coderroggie on Jun 23, 2016

Hi, I’m having a similar issue as discussed in this thread, except that I’m not even seeing the completed event. I’ve got live and retry set to true. When the credentials are all fine, then syncing is good. However, if the credentials are cleared (can happen if the user logs off in a different browser) then I can see 401 errors in the console. However, these do not get propagated and the sync continues to repeat. I would like to catch the 401 so that I can return to the log in screen.

My sync function is as follows:

 function sync(remoteDatabase) {
    syncHandle = database.sync(remoteDatabase, {
      live: true, retry: true
    }).on('denied', function (err) {
      // a document failed to replicate (e.g. due to permissions)
      console.log("SYNC DENIED!", err);
    }).on('error', function (err) {
      // handle error
      console.log("SYNC ERROR!", err);
    }).on('paused', function (err) {
      // replication paused (e.g. replication up to date, user went offline)
      console.log("PouchDB Sync PAUSED => ", err);
    }).on('change', function (info) {
      // handle change
      console.log("PouchDB Sync CHANGED => ", info);
    }).on('active', function (info) {
      // replicate resumed (e.g. new changes replicating, user went back online)
      console.log("PouchDB Sync ACTIVE => ", info);
    }).on('complete', function (info) {
      // handle complete
      console.log("PouchDB Sync COMPLETE => ", info);
    });
  }

If I log off in a different browser, I get the following message in the console:

Failed to load resource: the server responded with a status of 401 (Unauthorised)

However, none of the above events are fired (not even paused, which was being received when it was syncing).

Can anyone please help with detecting the 401?

Thanks, Giles

gillez on Jun 20, 2016

@axul that’s being discussed here

mkazlauskas on Jun 16, 2016