Database deleted after change

[csaroff]

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.