Network changed events causing replication to hang without error?
- Dominant language
- JavaScript
- Stars
- 17.6k
- Forks
- 1.5k
- PR merge metrics
- No merged PRs in 30d
Description
### Issue
We suspect PouchDB replicate is not recovering from a hanging long poll due to a network changed event.
The rest of this bug report is less than ideal in its vagueness, but I'm hoping it might trigger an idea of where to look in the code for someone, or at least act as a place for others to report similar problems.
What we are seeing is replications from browser to couchDB getting halted, alongside some NETWORK_CHANGED messages in the log. E.g.
```
db.example.com/mydb123/_changes?style=all_docs&feed=longpoll&heartbeat=10000&since=123-g1BBBBCbabcLYWxytzMpgpTpTQTMUv3___-zMpgTXYZAhappyyNACp_1DTHABChellowl4oqw&limit=1000:1
Failed to load resource: net::ERR_NETWORK_CHANGED
```
These are web apps that are used all day, and sometimes it seems to sort itself out, but sometimes after 20+ minutes of these it chokes with something like the below, and everything in the web app breaks:
```
vendor.js:30 {error: 'InvalidStateError', name: 'InvalidStateError', reason: "Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing.", message: "Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing.", status: 500}
```
In the log I'm looking at I have that message three times, over the space of 5 seconds.
We have 5 pouchDB instances active at a time, one is very busy, two have bursts of activity, the other two usually have no replications, in either direction, during a day.
This morning I found this very similar report, https://github.com/pouchdb/pouchdb/issues/8462, this paragraph in particular:
> Looking into the network traffic it seems the long poll for replication hangs and never detects the broken connection. Even setting the timeout setting when starting the replication doesn't seem to change this behavior. Finally, as the replication just hangs, no error events are emitted by the PouchDB.replicate.
That seems to match exactly what we are seeing. (Unfortunately, the stale bot closed it, because obviously no-one wants to touch a bug that is hard to reproduce.)
### Info
- Environment: Browser
- Platform: Seen in Chrome only so far, both Windows and Mac.
- Server: CouchDB running in AWS (two separate instances.)
### Reproduce
Sorry. It only happens sometimes, only in the wild, and we're having to piece evidence together from their console logs if we are lucky enough to be sent them. It does seem to be happening to the same few users, but they say browsing the internet is working fine for them at the time.
We've checked disk space, and machine load, asked them to reboot, etc. and have yet to find anything out of the ordinary there.
Contributor guide
Assessment
This issue has not been assessed yet.