Angular $exceptionHandler too sensitive

[dianabarsan]

It appears that all UnhandledPromiseRejections are being pushed as feedback to the DB by the new $exceptionHandler, including network connection errors.

Steps to reproduce:

• Checkout latest master (3.5)
• Deploy it - you don't need any configuration for this, just start the app
• I recommend deploying on an empty throw-away DB, as you're going to create thousands of identical feedback documents
• Login as admin
• Open the Dev tools network tab
• Go to Messages tab
• Keeping the network tab open, go offline (Via the network tab offline checkbox)
• Click on the "Send message" button
• Click "Cancel"

What should happen:

• Your popup should go away and no new requests should appear in the network log

What actually happens:

• The network tab quickly fills up with _bulk_docs requests that all fail (because we're offline).
• The requests counter should rise up quite quickly - don't wait too long, couple of seconds is enough
• Go online again (Via the network tab offline checkbox)
• It's very possible your browser will become unresponsive at this moment
• Login to Fauxton and verify that you have many docs (depends on how long you stayed offline - my computer generates about 2000 in a couple of seconds), all feedback docs, all identical, all saying Failed to fetch....

Some explanations

• Because our Modals are Promises that resolve when the user clicks "yes" and reject when the user clicks "no", not catching to the "no" qualifies as an unhandled promise rejection. We mostly do not catch "no"s if we don't want to do anything with them, so the above would be triggered on most modals in the app.
• Clicking on the "No" button qualifies as an unhandled promise rejection, which the $exceptionHandler will pick up and try to post a feedback doc with it (which is another bug)
• Because we are offline, the upload will fail, which will log another error which the $exceptionHandler will catch and will try to post a feedback doc with it
• Because we are offline, the upload will fail, which will log another error which the $exceptionHandler will catch and will try to post a feedback doc with it
• Because we are offline, the upload will fail, which will log another error which the $exceptionHandler will catch and will try to post a feedback doc with it
• You get the point

There are a number of other connection errors exception which are incorrectly reported as feedback, for example replication attempts of offline users when disconnected from the internet.

Sincere apologies if the steps described above have crashed your browser/computer

Environment:

• Instance: local
• Browser: Firefox, Chrome, Chromium, irrelevant
• Client platform: Linux
• App: webapp
• Version: 3.5

[dianabarsan]

Adding another scenario where the Exception Handler submits feedback about disconnects:

Steps to reproduce:

• Checkout latest master (3.5)
• Deploy it - you don't need any configuration for this, just start the app
• Login as an offline user
• Open the Dev tools network tab
• Keeping the network tab open, go offline (Via the network tab offline checkbox)
• Open the hamburger menu and click "Sync now"
• Go online
• In the hamburger menu, click "Sync Now"

What should happen

• The network tab should not report a _bulk_docs call (as you have not done any doc updates)

What actually happens

• In the network tab, observe a _bulk_docs call creating a feedback doc reporting failing to replicate

{"meta":{"time":"2019-03-25T14:47:37.467Z","user":{"name":"chw1","roles":["district_admin"]},"url":"http://127.0.0.1:6500/medic/_design/medic/_rewrite/#/reports/","app":"medic","version":"3.5.0","source":"automatic"},"info":{"message":"","cause":"Possibly unhandled rejection: {\"result\":{\"ok\":false,\"start_time\":\"2019-03-25T14:47:37.428Z\",\"docs_read\":0,\"docs_written\":0,\"doc_write_failures\":0,\"errors\":[],\"status\":\"aborting\",\"end_time\":\"2019-03-25T14:47:37.459Z\",\"last_seq\":0}}"},"log":[],"type":"feedback","_id":"1e0231dc-ffba-4234-ae53-79080b03f1ad","_rev":"1-21e2e6f272ecdd6bd9818a9642334cdb"}

[peter-ochieng]

Ready for AT on stop_infinite_feedback_loops

[newtewt]

Another one down. Looks good in AT