Affects Version/s: 2.0.0
Fix Version/s: 2.0.0
I discovered this issue whilst running the PouchDB test suite against CouchDB 2.0 (in a cluster of 1). It's a bit of an edge case but, essentially, the steps to reproduce are:
1. create a database /foo
2. insert 2 empty documents with _ids "a" and "b"
3. call /foo/_changes?limit=1. Note the ETag returned in the response
4. delete /foo
5. recreate database /foo
6. insert 2 empty documents with _ids "a" and "b"
7. call /foo/_changes?limit=1, passing an "If-None-Match" header using the ETag value captured in (3)
8. CouchDB 2.0 returns a 304 Not Modified response - CouchDB 1.6 returns a 200 and ignores the If-None-Match value
The problem for the client is that it would use the cached value from (3) which is invalid for this recreated database.
A full reproduction is at https://gist.github.com/willholley/c5f4c30fce822dc7dc48cbc8875c394b with the CouchDB 1.6 equivalent at https://gist.github.com/willholley/c0b9c6cf2a62090ac3bee4fa549644bd.
Bob Newson suggested that this was likely down to CouchDB 1.6 using the instance_start_time when calculating the ETag for _changes, invaliding previously returned ETags if a database is deleted and recreated with the same parameters. In 2.0, instance_start_time is always 0 so we need to use a different property to ensure unique ETags per database instance (e.g. the unique shard suffix).