I'm currently using follow through the nano api to listen on the changes feed of a cloudant database. I've noticed an issue where follow will kill itself with the following error
Error: Database deleted after change: 89799568-g1AAAAJHeJzLYWBg4MhgTmGQT0lKzi9KdUhJMjTWy0zKNTAw10vOyS9NScwr0ctLLckBKmRKZEiS____f1YGUxLDamvbXKAYu6GpYbKRsTnIDDm4GeY4jUhSAJJJ9nBToprBpphZJBuZWCYT7ZIkB5Ax8XBjPE6AjTExSTS2NEsj3pgEkDH1cGPsfSDGWJglJ1ukEeunPBYgydAApIAGzYeYFP0D4q9EQ2NDS3M0BxkRMGoBxKj9EKNsjoCNsjAwTEyxtCTNUQcgJt2HmBToCTbJINnINMUwBdUkMwImPYCYBA0o4-1gkyyT09IsUiyzAH6UsGc
at Feed.on_couch_data (/Users/csaroff/CloudOE/segment/loginlistener/node_modules/nano/node_modules/follow/lib/feed.js:440:18)
at Changes.handle_confirmed_req_event (/Users/csaroff/CloudOE/segment/loginlistener/node_modules/nano/node_modules/follow/lib/feed.js:325:30)
at Changes.emit (events.js:107:17)
at Changes.emit_changes (/Users/csaroff/CloudOE/segment/loginlistener/node_modules/nano/node_modules/follow/lib/stream.js:223:12)
at Changes.write_continuous (/Users/csaroff/CloudOE/segment/loginlistener/node_modules/nano/node_modules/follow/lib/stream.js:176:8)
at Changes.write (/Users/csaroff/CloudOE/segment/loginlistener/node_modules/nano/node_modules/follow/lib/stream.js:124:17)
at Request.ondata (stream.js:51:26)
at Request.emit (events.js:107:17)
at IncomingMessage.<anonymous> (/Users/csaroff/CloudOE/segment/loginlistener/node_modules/nano/node_modules/follow/node_modules/request/request.js:1164:12)
at IncomingMessage.emit (events.js:107:17)
at readableAddChunk (_stream_readable.js:163:16)
at IncomingMessage.Readable.push (_stream_readable.js:126:10)
at HTTPParser.parserOnBody (_http_common.js:132:22)
at TLSSocket.socketOnData (_http_client.js:317:20)
at TLSSocket.emit (events.js:107:17)
at readableAddChunk (_stream_readable.js:163:16)
at TLSSocket.Readable.push (_stream_readable.js:126:10)
at TCP.onread (net.js:538:20)
It seems that the issue is being caused because cloudant is sending a last_seq in a continuous change which follow incorrectly interprets as a dropped database.
last_seq can occur on cloudant timeouts. I propose that connection restart be attempted instead of throwing an error and killing the connection.
I'm currently using follow through the nano api to listen on the changes feed of a cloudant database. I've noticed an issue where follow will kill itself with the following error
It seems that the issue is being caused because cloudant is sending a last_seq in a continuous change which follow incorrectly interprets as a dropped database.
last_seq can occur on cloudant timeouts. I propose that connection restart be attempted instead of throwing an error and killing the connection.